Ah, thanks for giving me a heads up Jonas. I'll have to wait and see
where it goes then. Do you have a page/blog where I can keep up to date
with your progress/roadmap of it? :)
- Den
On 2015-07-13 05:15 AM, Jonas Maebe wrote:
Den wrote:
I was just wondering if there was an option to enable compiling to
LLVM bitcode? I see a bit of work happening in SVN from it, and would
love to start using it.
You cannot use it, because it does not work yet. And as mentioned in
earlier messages:
* it will need architecture and OS-specific support per target (I'm
only working on Darwin/x86-64 right now)
* it will probably only work with specific LLVM versions, because LLVM
only cares to an extremely limited extent about backward/forward
compatibility
* LLVM's handling of parameter passing is split between Clang and LLVM
in a way that makes it impossible for third parties to support it in a
reliable way (although some people are looking into splitting off that
functionality into a - C++ - library; not sure how useful that would
be for FPC)
LLVM also makes a lot of assumptions that are wrong as far as non-C
languages are concerned. For example, the result of a load from a nil
address is considered to be "undefined", which means they (and every
instruction that depends on such a result) may be "optimised" away
completely by LLVM. In Pascal (or at least FPC), you instead expect a
segmentation fault if that happens. You can find a few other such
issues documented at
http://www.mono-project.com/docs/advanced/runtime/docs/llvm-backend/ ,
but there are more. They are open to fixing such assumptions (or to at
least add a command line parameter to disable them), but I'm not aware
of anyone actually working on LLVM to do this (and I'm not going to do
that myself either).
Finally, it is not possible at this time to combine units compiled
with a regular code generator with units compiled with LLVM due to
differences in the PPU format between the two. I don't know if it will
be possible to solve this without a significant rewrite of in
particular our handling of inline functions.
Just to say: don't get your hopes up that it will just be a simple
"recompile and take advantage of all LLVM features", especially in the
beginning.
Jonas
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
