[fpc-pascal] LLVM Backend Support

Jonas Maebe jonas.maebe at elis.ugent.be
Fri Aug 19 09:55:41 CEST 2016

African Wild Dog wrote:

> What is the current status of the LLVM backend support?

"make cycle" works on my machine for Darwin/x86-64, and most test suite
failures (apart from exception handling tests if the optimisation level
is increased, see point 2 below) are related to LLVM limitations rather
than to bugs in the FPC code generator to LLVM. I have not yet committed
everything, because some changes still need to be implemented in a
cleaner way.

The main missing features before the result is usable for real world
code are
1) support for inline assembler blocks in Pascal routines (they are
currently silently discarded). On the other hand, pure assembler
routines are already handled correctly (routines with only an "asm ...
end" block and no "begin ... end")
2) LLVM has support for explicit setjmp/longjmp (which we use on most
platforms for exception handling), but I still have to mark all accesses
to local variables in exception blocks as "volatile" because otherwise
they are not guaranteed to keep their value (similar to how we disable
register variables in code that may trigger an exception). A future,
better, way may be to use LLVM's built-in primitives for exception handling.
3) possibly support for debug information generation

There are also a few LLVM limitations over which I have no influence:
a) LLVM has no support for arbitrary instructions throwing exceptions.
I.e., segmentation faults, alignment exceptions, bus errors, floating
point exceptions etc are not supported in any way by LLVM. If it can
prove at compile time that a non-floating point exception will happen
(e.g., you store nil in a pointer and immediately dereference it), it
will simply interpret the exception-causing instruction as having
"undefined behaviour", which generally results in pretty much all code
depending on the result of that instruction getting "optimised" away. In
case of floating point exceptions, LLVM will replace the result of the
instruction with Inf/Nan at compile time. They are aware of this
), but there is no one actively working on it right now
(https://groups.google.com/forum/#!topic/llvm-dev/7yLycHmeydo )
b) LLVM has no support for the i386 "register" calling convention, so I
will probably never add support for the i386 target using LLVM

As alluded to above, LLVM support needs to be added/tested/maintained
separately for each supported architecture and to a lesser extent for
each supported OS. Right now, I only have plans for x86-64 and AArch64
(and maybe PowerPC64), on Darwin and Linux. Personally, I won't add
support for Windows since I don't use that platform. Support for 32 bit
platforms in general will be a bit tricky due to the way our compiler is


More information about the fpc-pascal mailing list