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 limitation (http://llvm.org/devmtg/2015-10/slides/KlecknerMajnemer-ExceptionHandling.pdf ), 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 structured. Jonas _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal