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

[Jonas Maebe]

On 17/11/18 22:15, Simon Kissel wrote:

> How far of a way is that? Sadly we'll have to support some 32 bit
> platforms for a couple more years...

I really don't know. It's not something I have looked into, but I'm 
afraid it will be messy.

> And how far away is getting this to run on Linux?

Getting it to work on Linux/x86-64 should be fairly easy. Other 64 bit 
platforms (both architectures and OSes) should not be difficult either.

> And: Any language features or RTL stuff that does not yet work
> with FPC/LLVM?

Only the ones mentioned before:
* global variables are currently not treated as volatile by the LLVM 
code generator, so if you use them to share values between threads with 
explicit synchronisation, that will fail (as Sven explained)

* hardware exceptions (like segmentation faults, fpu exceptions and bus 
errors) because LLVM does not model them. I could try to work around 
this by making all accesses to all variables potentially referenced in 
try/except blocks "volatile" (both in the blocks and afterwards), but 
that would prevent many optimizations and it would not even guarantee to 
solve all potential problems (since the LLVM code generator would still 
assume that if those instructions trap, all behaviour afterwards is 
undefined and hence it can optimize as if those instructions will never 
trap; marking them as volatile won't change that: even if in many cases 
the end result may be the same, it's not guaranteed).

   The only work done on LLVM in this regard is some experimental 
support for FPU exceptions in recent versions 
(https://llvm.org/docs/LangRef.html#constrained-floating-point-intrinsics), 
but I have not yet added support for that yet (nor do I know how well it 
works, or on which platforms it is supported).

> Bonus question: I don't know on which layer threads and exceptions are
> handled with LLVM - will you be able to make use of the improvements to
> TLS and Exception handling, in other words, can we combine the best
> of both worlds?

The only improvements to exception handling until now have been for the 
LLVM target. The code I already submitted is generic though, and can be 
used by non-LLVM targets as well.

TLS-based threadvar support needs to be implemented separately for LLVM, 
but that should be fairly easy (it's just another way of declaring the 
variable in the LLVM IR.


Jonas