When I had a look at the CLBG results last time the code generated by FreePascal was even about three to four times slower than C/C++; but the benchmark rules are not particularly well suited for fair comparison (some code is obviously written with inside knowledge of the particular compiler/version and not what you usually see for the given language, and the Pascal code likely includes range and overflow checks which make it slower compared to a language without these, etc.). The LLVM backend is not officially supported by FP and doesn't support all platforms as far as I know; and unfortunately micro benchmarks are usually not representative for the daily overall performance of an application; the Are-we-fast-yet benchmark suite would be better in this regard.

Anyway, I would be interested in why FP benchmarked as fast as C++ in the past, but no longer today.

> 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.

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.

> 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.h...

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).

I read somewhere that there are issues with higher optimization levels. Can you confirm that?

> 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).

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

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.

Yeah, Free Pascal is far from simple. It not only tries to implement everything Delphi provides (itself never being a "simple" language) but also as much as other Pascal dialects provide (via compiler modes) and various useful features from other languages - and that in backwards compatible ways (often via "modeswitches" - kinda like submodes).

With that in mind it is kinda interesting that there are (AFAIK) three parsers for it anyway: FPC itself, lcl-passrc and Lazarus' CodeTools. It does mean that any new stuff in the language gets some time to be implemented in others though.

> Free Pascal is far from simple.

It's still much less complex than e.g. Ada or C++, and unfortunately, the language has redundant, competing concepts that are probably explained by - as you say - putting different languages and design styles together; it's definitely not my favorite language.

Unfortunately, there was also no complete and correct grammar, so I had to create one myself, and even in this one there are still productions without definition, e.g. array_constant, record_constant and procedural_constant. At least the syntax diagrams were not left recursive, and also removing ambiguous alternatives was straight forward.

Surprisingly, the FP language specification does not distinguish between language variants; only the compiler knows different modes. There seems to be a common grammar for all modes.