[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: Tue, November 10, 2009 3:46:59 PM
> Subject: Re: [fpc-devel] LLVM Backend?
> 
> 
> On 10 Nov 2009, at 21:35, Samuel Crow wrote:
> 
-snip-
> > Do the object-oriented features of FPC require name-demangled C bindings 
> rather than the raw C++ name mangling techniques?  Reason:  If we can call C++ 
> code directly we can invoke the LLVM code generation classes to go directly to 
> bitcode rather than tinkering with the Assembly parser of LLVM.
> 
> We have a C++ name mangler in the compiler, but it's
> a) barely used/tested
> b) only usable for calling regular functions/procedures, not for calling methods 
> (someone recently started some preliminary work on supporting that though)
> 
> In general, the most common way to interface with external C++ libraries is 
> indeed via C wrappers.
> 
> Directly linking against LLVM (be it via C or C++) would also only seem 
> advisable if that API is considered stable. One of the main pluses of FPC is 
> that both the compiler and the generated programs are generally very much 
> forward and backward compatible. E.g., you can run FPC and FPC-compiled binaries 
> on any 2.4+ kernel Linux system, with no dependencies on glibc versions or 
> anything else. Same goes for Mac OS X: the PPC compiler run on 10.3+, and the 
> compiled binaries on 10.2.8+. For Windows it's also similar.
> 
> With an LLVM backend, there will obviously be a dependency on LLVM (either as a 
> library or as an installed tool chain) and hence on its dependencies, but it 
> would be nice if we could be compatible with as many different LLVM releases as 
> possible at the same time (so that people having to stick to an older LLVM 
> version for whatever reason can upgrade FPC independently of that). In that 
> respect, I don't know to what extent the C++ interface of the LLVM code 
> generator is more or less stable than the assembler format (I know that the LLVM 
> developers reserve the right to break backwards compatibility in the assembler 
> format only when releasing new major versions).
> 

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

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

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.

--Sam Crow