[fpc-devel] LLVM Backend?

[Jonas Maebe]

On 11 Nov 2009, at 04:29, Samuel Crow wrote:

> The IRBuilder class http://llvm.org/doxygen/classllvm_1_1IRBuilder.html 
>  is as stable as the instruction set it builds and is maintained as  
> such since it is used by Clang, LLVM-GCC and other frontends.

Ok, that would be fine then. The only problem is actually interfacing  
with the C++ classes then, because as mentioned that's not supported  
currently.

> As noted in other messages on the list, the LLVM-FPC compiler would  
> be heavily dependent on LLVM and, in turn, would require newer  
> operating system support for the compiler to run on MacOSX 10.4, for  
> example, (primarily because of the linker and debugger situation on  
> the earlier models' XCode versions) since that's the earliest that  
> LLVM supports.  I have a 10.3.9-based PowerMac G4 that we could test  
> the resultant code on, but I'm not holding my breath to think that  
> it will work.

In a sense it's no problem if the LLVM backend doesn't support all  
targets that the other backends support, after all it'll be just  
another choice that people can use. I just want to avoid the LLVM  
backend being completely disconnected from the other backends or  
require an inordinate amount of maintenance to keep it in sync with  
the other backends, because in that case it would probably be quite  
short-lived (unless some dedicated maintainer would step up and  
constantly keep it in sync with the rest).

> I think the runtime library and frontend parser would be needed more  
> than the rest of the FPC compiler itself.  Most of the backend and  
> intermediate code in the FPC optimizer would be redundant with LLVM.

As I see it, there are basically two approaches to integrate a  
compiler with LLVM:
a. the LLVM-GCC approach, where you bolt an existing compiler's  
frontend onto llvm
b. the dragonegg approach (http://dragonegg.llvm.org/), where you make  
use of the support in an existing compiler (again GCC in this case)  
for abstract code generator support to emit LLVM assembler/bitcode  
rather than machine code

I am very much in favour of approach b, because I think it's the only  
one that can stand the test of time (in case a, you you constantly  
have to keep your "bolts" up-to-date as the frontend evolves).

FPC already has a fairly abstract code generator interface, because we  
don't use intermediate code: parse tree nodes are translated into  
machine code by calling the appropriate code generator class methods.  
The existing abstract code generator's interface is lower level than  
LLVM's as far as the type info is concerned though, so we need a  
higher level (either sitting above the current code generator, or  
replacing existing code generator).

> The reason I'm not afraid to redo most of the internals of FPC is  
> that I am involved in a compiler project already and would need to  
> reuse the code for that project also.  Before I noticed that there  
> was an LLVM backend already started for FPC I was going to take the  
> parser description from the documentation and start from scratch  
> anyway.

As mentioned before, I do not think the end result of such an approach  
would be sustainable in the long term (unless all code generators  
would be removed in favour of the LLVM backend, but I don't see that  
happening for a variety of reasons).

> I'm looking forward to the challenges of this project.  I hope I  
> haven't scared you all with my brashness (and yes I am a little  
> crazy also).  I'll talk to you more later.

Thanks for your interest!


Jonas