[fpc-devel] The 15k bounty: Optimizing executable speed for Linux x86 / LLVM

[Florian Klämpfl]

Am 27.10.2018 um 18:21 schrieb Ben Grasset:
> On Sat, Oct 27, 2018 at 8:47 AM Jonas Maebe <jonas at freepascal.org <mailto:jonas at freepascal.org>> wrote:
> 
>     On 27/10/18 05:45, Ben Grasset wrote:
> 
>   
> 
>     You also need "opt" if you want to perform full optimizations (or just
>     use clang, which a.o. combines the functionality of llc and opt).
> 
>     There's one more problem I forgot to mention in my first post, and it is
>     probably a deal breaker for the original bounty: LLVM does not support
>     Borland's fastcall calling convention for i386. So you would need to add
>     support for Borland fastcall on i386 to LLVM if it has to support
>     existing i386 inline assembly routines written for FPC/Delphi.
> 
>     Finally, adding support for 32 bit targets in FPC's LLVM backend would
>     also require some work due to how FPC's code generator is structured,
>     and due to the fact that need to have two code generators in a single
>     binary (the native one to support the generation of entry and exit code
>     for pure inline assembler routines, and the LLVM one for the rest).
> 
> 
> LLC (at least now) statically links the necessary parts of LLVM and works independently of Opt, with a simpler set of
> command line options (it just has overall O1, O2, and O3 flags.)
> 
> As far as the point about assembly on 32 bit, while it does seem like that would be a problem for the bounty
> requirements, would it really be the end of the world in a more general sense? I can't imagine people who are still
> using 32-bit-hardware and writing 32-bit applications would complain if the LLVM backend was not available for 32-bit.
> 
> Anyways though, I do think code gen improvements for FPC, LLVM or not, are likely going to be a lot more widely helpful
> than just rewriting exception handling.... 

If you read the whole thread, LLVM needs a rewritten exception handling as well. Further, a quick test
of table based exception handling on bansi1 (which is mainly a memory manager test) gives:

standard exception handling:

fpctrunk\tests\bench>pp11 bansi1 -O3

fpctrunk\tests\bench>bansi1
Test 1: 1000000 done in 0.537 sec
Test 2: 1000000 done in 0.535 sec
Test 3: 1000000 done in 0.587 sec

SEH based exception handling:

fpctrunk\tests\bench>pp11 bansi1 -O3

fpctrunk\tests\bench>bansi1
Test 1: 1000000 done in 0.456 sec
Test 2: 1000000 done in 0.457 sec
Test 3: 1000000 done in 0.446 sec