Pascal sources optimisation

[matthius]

Deepseek allowed me a few moment to create an optimiser of pascal code.

I have tested it on my sources.

Here it is :
https://sourceforge.net/projects/pascalboost/files/

[Martin_fr]

I haven't looked in depth into it. But I saw that there is "const param optimization".

Which hopefully is done correctly? If done with strings (dyn-array, or other managed types) then this can lead to crashes. That has been explained various times, here on the forum.

Code: Pascal  [Select][+][-]

1. procedure foo(const data: string);

even if there is no write access to the variable "data", if there is

Code: Pascal  [Select][+][-]

1. var text: string;
2. begin
3.   foo(text);

And in any way (nested calls, callback, events, pointers, whatever) "text" is write accessed (while in foo, or in anything called nested by foo) => then this can crash.

Note: "can" => "may" or "has the potential to sometimes".
In most simple cases and test, it will not show any problem. But when you have more real code than a demo, then it can. 

Even the IDE itself had that issue at least once, and it had crashed for some people because of it.

[Martin_fr]

I also saw something about "virtual"....

FPC has de-virtualization as part of WPO (Whole Program Optimization). Just in case that is what it does.

[matthius]

I am upgrading with optimisation and separating it.

[Thaddy]

Quite a lot "keywords" missing (they are not always keywords). This list is by no means complete but should be added:
Alias, operator, external,cdecl,stdcall,winapi,pascal,reference, probably more.

[ALLIGATOR]

An idea for optimization is to redistribute the fields of classes/records/objects so that they have as little loss as possible due to padding between elements:

Code: Pascal  [Select][+][-]

1. program app;
2. {$mode objfpc}
3. type
4.   TC1 = class
5.     a: byte;
6.     b: double;
7.     c: byte;
8.     d: double;
9.     e: byte;
10.     f: double;
11.     g: byte;
12.     h: double;
13.   end;
14.   TC2 = class
15.     b: double;
16.     d: double;
17.     f: double;
18.     h: double;
19.     a: byte;
20.     c: byte;
21.     e: byte;
22.     g: byte;
23.   end;
24.  
25. begin
26.   WriteLn(TC1.InstanceSize);
27.   WriteLn(TC2.InstanceSize);
28. end.

[Martin_fr]

An idea for optimization is to redistribute the fields of classes/records/objects so that they have as little loss as possible due to padding between elements:

https://wiki.freepascal.org/FPC_New_Features_3.0.0#Class_field_reordering

It is not done for records, since they often are used to represent specific layouts, as specified by some spec (e.g. for interchanging data with other apps, and then both sides must have identical layouts)