4 ms·

> The LLVM backend is not officially supported by FP It used to be a separate project but these days is part of the main development branch. Though indeed the

> The LLVM backend is not officially supported by FP It used to be a separate project but these days is part of the main development branch. Though indeed the OS and CPU support is very limited. Also i agree about the micro benchmark comparison, they tend to exaggerate differences. FWIW in my own programs i never found Free Pascal's code generator to be inadequate. I do not remember the exact difference but last year i did compile my 3D game engine with the LLVM backend and the difference was small enough for me to decide that i don't want to bother with the much slower compile times.

Rochus 3y ago
I read other comments of people claiming the code generated by the LLVM backend was less than factor 1.5 faster than the one generated by the original backend, which is not worth the effort (and the humongous overhead and additional dependencies) from my point of view; but I'm still trying to find information about the specific optimizations done in the current FP compiler.
- badsectoracula 3y ago
  > I'm still trying to find information about the specific optimizations done in the current FP compiler. AFAIK there isn't any explicit documentation but the "toptimizerswitch" and "twpoptimizerswitch" (the latter is for whole program optimizations) types in the compiler define the available optimizations in globtype.pas and have the following values: cs_opt_level1,cs_opt_level2,cs_opt_level3,cs_opt_level4, cs_opt_regvar,cs_opt_uncertain,cs_opt_size,cs_opt_stackframe, cs_opt_peephole,cs_opt_loopunroll,cs_opt_tailrecursion,cs_opt_nodecse, cs_opt_nodedfa,cs_opt_loopstrength,cs_opt_scheduler,cs_opt_autoinline, cs_useebp,cs_userbp,cs_opt_reorder_fields,cs_opt_fastmath, cs_opt_dead_values,cs_opt_remove_empty_proc,cs_opt_constant_propagate, cs_opt_dead_store_eliminate,cs_opt_forcenostackframe, cs_opt_use_load_modify_store,cs_opt_unused_para,cs_opt_consts, cs_opt_forloop cs_wpo_devirtualize_calls,cs_wpo_optimize_vmts,cs_wpo_symbol_liveness level1/2/3/4 are basically collections for some of the above and are enabled for -On where n is 1 to 4. You can enable optimizations explicitly with the -OoXXX (for per-module optimizations) and -OwXXX (for whole program optimizations). The -io and -iw parameters can be used to obtain the available names for these. I think the names are more or less self-explanatory, at least for the most part (not sure what "uncertain" does... which i think is appropriate :-P). Some brief documentation (though very brief) is available in the programmer's guide: https://www.freepascal.org/docs-html/current/prog/progch11.html#x235-24900011 https://www.freepascal.org/docs-html/current/prog/progch11.h...
  - Rochus 3y ago
    Thanks for the hints. I was already concerned that I would have to analyze the source code directly myself, and so I started to build tools for this purpose (https://github.com/rochus-keller/FreePascal https://github.com/rochus-keller/FreePascal). I read somewhere that there are issues with higher optimization levels. Can you confirm that?
    - badsectoracula 3y ago
      > Thanks for the hints. I was already concerned that I would have to analyze the source code directly myself, and so I started to build tools for this purpose (https://github.com/rochus-keller/FreePascal https://github.com/rochus-keller/FreePascal). FWIW you may want to check out the fcl-passrc package[0] which provides units for scanning and creating a syntax tree from FPC source code, including some helpers like resolving references. It is used by the fpdoc documentation generator and the pas2js transpiler that converts Free Pascal source code to JavaScript, both official FPC projects. fcl-passrc is itself part of Free Pascal. > I read somewhere that there are issues with higher optimization levels. Can you confirm that? AFAIK the main issue is that -O4 enables some optimizations that may break code that relies on things like having the exact same math output as non-optimized versions as it enables FASTMATH, code that relies on classes having specific field order (technically class field order is not guaranteed to remain the same) since -O4 enables reordering the fields to remove unnecessary padding and code that depends on runtime errors or exceptions being thrown from code that the compiler (in -O4) decided it has not explicit side effects and removed it. These are not "issues" per-se but Lazarus labels -O4 as having "aggressive optimizations, beware" which might give a false impression. Aside from that there might be bugs, but that is the case with any compiler. [0] https://wiki.freepascal.org/fcl-passrc https://wiki.freepascal.org/fcl-passrc
      - Rochus 3y ago
        Thanks again for the hints; I'm not (yet) fluent with FreePascal and assumed to be much faster when quickly implementing a rudimentary parser to make arbitrary queries over the source code (the one I implemented for Lisa Pascal/Clascal including the browser/cross-referencer took a week as a side project) than discovering and learning all the required FP libraries and tools; but the FP language turned out to have some pretty dark corners which are much harder to parse than I expected from a Pascal descendant.

Rochus 3y ago

I read other comments of people claiming the code generated by the LLVM backend was less than factor 1.5 faster than the one generated by the original backend, which is not worth the effort (and the humongous overhead and additional dependencies) from my point of view; but I'm still trying to find information about the specific optimizations done in the current FP compiler.

badsectoracula 3y ago
> I'm still trying to find information about the specific optimizations done in the current FP compiler. AFAIK there isn't any explicit documentation but the "toptimizerswitch" and "twpoptimizerswitch" (the latter is for whole program optimizations) types in the compiler define the available optimizations in globtype.pas and have the following values: cs_opt_level1,cs_opt_level2,cs_opt_level3,cs_opt_level4, cs_opt_regvar,cs_opt_uncertain,cs_opt_size,cs_opt_stackframe, cs_opt_peephole,cs_opt_loopunroll,cs_opt_tailrecursion,cs_opt_nodecse, cs_opt_nodedfa,cs_opt_loopstrength,cs_opt_scheduler,cs_opt_autoinline, cs_useebp,cs_userbp,cs_opt_reorder_fields,cs_opt_fastmath, cs_opt_dead_values,cs_opt_remove_empty_proc,cs_opt_constant_propagate, cs_opt_dead_store_eliminate,cs_opt_forcenostackframe, cs_opt_use_load_modify_store,cs_opt_unused_para,cs_opt_consts, cs_opt_forloop cs_wpo_devirtualize_calls,cs_wpo_optimize_vmts,cs_wpo_symbol_liveness level1/2/3/4 are basically collections for some of the above and are enabled for -On where n is 1 to 4. You can enable optimizations explicitly with the -OoXXX (for per-module optimizations) and -OwXXX (for whole program optimizations). The -io and -iw parameters can be used to obtain the available names for these. I think the names are more or less self-explanatory, at least for the most part (not sure what "uncertain" does... which i think is appropriate :-P). Some brief documentation (though very brief) is available in the programmer's guide: https://www.freepascal.org/docs-html/current/prog/progch11.html#x235-24900011 https://www.freepascal.org/docs-html/current/prog/progch11.h...
- Rochus 3y ago
  Thanks for the hints. I was already concerned that I would have to analyze the source code directly myself, and so I started to build tools for this purpose (https://github.com/rochus-keller/FreePascal https://github.com/rochus-keller/FreePascal). I read somewhere that there are issues with higher optimization levels. Can you confirm that?
  - badsectoracula 3y ago
    > Thanks for the hints. I was already concerned that I would have to analyze the source code directly myself, and so I started to build tools for this purpose (https://github.com/rochus-keller/FreePascal https://github.com/rochus-keller/FreePascal). FWIW you may want to check out the fcl-passrc package[0] which provides units for scanning and creating a syntax tree from FPC source code, including some helpers like resolving references. It is used by the fpdoc documentation generator and the pas2js transpiler that converts Free Pascal source code to JavaScript, both official FPC projects. fcl-passrc is itself part of Free Pascal. > I read somewhere that there are issues with higher optimization levels. Can you confirm that? AFAIK the main issue is that -O4 enables some optimizations that may break code that relies on things like having the exact same math output as non-optimized versions as it enables FASTMATH, code that relies on classes having specific field order (technically class field order is not guaranteed to remain the same) since -O4 enables reordering the fields to remove unnecessary padding and code that depends on runtime errors or exceptions being thrown from code that the compiler (in -O4) decided it has not explicit side effects and removed it. These are not "issues" per-se but Lazarus labels -O4 as having "aggressive optimizations, beware" which might give a false impression. Aside from that there might be bugs, but that is the case with any compiler. [0] https://wiki.freepascal.org/fcl-passrc https://wiki.freepascal.org/fcl-passrc
    - Rochus 3y ago
      Thanks again for the hints; I'm not (yet) fluent with FreePascal and assumed to be much faster when quickly implementing a rudimentary parser to make arbitrary queries over the source code (the one I implemented for Lisa Pascal/Clascal including the browser/cross-referencer took a week as a side project) than discovering and learning all the required FP libraries and tools; but the FP language turned out to have some pretty dark corners which are much harder to parse than I expected from a Pascal descendant.