[fpc-devel] LLVM Backend?

[Jonas Maebe]

On 10 Nov 2009, at 21:35, Samuel Crow wrote:

> The current way to implement pointer arithmetic in LLVM is to use an  
> i64 for all instances of pointers

We can't do that at the high level, since then all pointer fields in  
records etc would become 64 bit. And the low level currently assumes  
that register sizes are the same as the pointer size. I have started  
in the past at trying to break these assumptions, but it's not  
straightforward.

> and then bitcast them to and from the correct pointer type when they  
> are needed as actual pointers and then use the GetElementPointer  
> operation to do the pointer-specific addressing modes.

Somehow, we have to integrate the high level type information in the  
assembler instructions though. For example when doing a function call,  
you have no choice but to use the real high level function types,  
otherwise LLVM can't know how to pass the parameters (e.g. record/ 
struct by value). This requires changes in all code generators for all  
platforms if we want to keep using the same code generator abstraction  
for everything (which I would very much prefer -- we currently  
maintain 6 different code generators with maybe 3 or 4 people, and  
that's only possible because so much is shared and generic).

> If the 64-bit int is bigger than what is needed to hold a pointer  
> and all uses are bitcast to pointers, the LLVM optimizer figures  
> that out and down-converts it to 32-bits.  It's messy but it works.   
> There is a proposal to make a new primitive type to represent the  
> pointer-sized integer being circulated on the LLVM-Developer mailing  
> list right now so we'll see if anything comes of it.

Yes, I saw that (although I'm 8000+ mails behind on the llvm-dev list :)

> Considering that LLVM generates code according to the specified  
> alignment characteristics given on one of the first lines of the  
> LLVM Assembly source file, it might be worth the great pains it  
> takes to propogate types down the pipe a bit.  It may soon be  
> possible to write a bitcode file that will compile down to all of  
> the platform-specific formats from the generic format like Java  
> or .NET does (except faster).

That would indeed be very nice!

> LLVM supports custom calling conventions in the backend so I'd have  
> to write a patch to the x86 backend to get it to take Borland  
> fastcall convention.  According to http://llvm.org/docs/LangRef.html#t_floating 
>  the 80-bit x87 floating point type is supported but only on the  
> respective platforms.

That's fine, as the same goes for FPC.

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

> Would it be too soon to announce that FPC will use LLVM in the  
> future?  Reason:  If I can submit a patch directly to the LLVM  
> repository for Borland fastcode calling convention on x86, I may be  
> able to ask for help from the existing LLVM developers on their  
> mailing list.

I don't see any problem at all with announcing that people are working  
on an LLVM code generation backend for FPC. I even already did so  
myself a long time ago on llvm-dev (http://lists.cs.uiuc.edu/pipermail/llvmdev/2007-June/009282.html 
  -- it's quite annoying that the mailing list archive is blocked from  
all search engines via a robots.txt file, not sure why that is).  
Obviously, that work stalled at some point.


Jonas