[fpc-devel] Enable LLVM?

[Den]

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 at lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel