[fpc-devel] LLVM Backend?

[Samuel Crow]

----- Original Message ----
> From: Jonas Maebe <jonas.maebe at elis.ugent.be>
> To: FPC developers' list <fpc-devel at lists.freepascal.org>
> Sent: Wed, November 11, 2009 5:03:52 AM
> Subject: Re: [fpc-devel] LLVM Backend?
> 
> 
> On 11 Nov 2009, at 04:29, Samuel Crow wrote:
> 
> > 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).
> 

What I originally had in mind was to use the LLVM support classes based on C bindings for libstdc++ and LLVM's template libraries.  See http://llvm.org/docs/ProgrammersManual.html for LLVM's best practices.  So, as such, it wouldn't be entirely disconnected from the rest of the project.  It would just be another LLVM frontend.  As for the code maintenance, the Mattathias BASIC team would be using the code for our compiler in the future as well so we'd have to protect it from bitrot.  Unfortunately something so drastic would be like a fork of the project and I like the fact that FPC will work on my old PowerMac G4 as well as the newer systems.  I was also hoping to avoid having to write our compilers as GCC frontends as well since that framework is poorly documented.

> > 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).
> 

We may want to replace the existing code generator, unfortunately.  The reason that LLVM requires such high-level code for the calling routines is that it supports not only different calling conventions but it promotes from the stack-based C calling convention to a register-loaded fastcall convention whenever possible.  This may not have been necessary when using the Borland Fastcall convention but sometimes being able to rearrange the registers when calling different functions can avoid some spillage to the stack.

I think the biggest obstacles to using LLVM at this point is that Borland Fastcall isn't supported by the x86 backend for LLVM and that the type information isn't high-level enough in the FPC compiler.  That's two problems, both fairly significant (although the latter is definitely heavier than the former).  Do you think it's too soon to divide out the work?  Is there more that needs discussion?

Let me know what you think.

--Sam Crow