[fpc-devel] LLVM Backend?

[Jonas Maebe]

On 10 Nov 2009, at 19:28, Samuel Crow wrote:

> I'd like to help with the experimental LLVM backend if anyone is  
> interested.  It's been years since I've used Pascal though, so  
> perhaps my familiarity with C and C++ on the LLVM end will be  
> beneficial.

Thanks for the offer!

> While we're on the subject, LLVM has a very powerful optimizer that,  
> when used in conjunction with Mono, speeded up execution time of  
> calculations quite substantially.  I thought I read somewhere on the  
> roadmap of using Static Single Assignment-related optimizations  
> being needed on FPC.  LLVM does all of those optimizations quite  
> naturally since its instruction set uses SSA throughout.

Yes, that's the main reason I started the LLVM backend.

> My reason for wanting to help is that I'm already involved in a  
> project for bringing an old version of BASIC up to date from the  
> days of the Amiga computer.  The member of our team responsible for  
> writing the runtime library is using Delphi but the parser writer  
> and I want to run it on any LLVM-supported platform.  Thus enters  
> FPC into the scene.
>
> If there's anything I can do to help, please reply on the list or  
> drop me a private email.

The main things that basically halted my work on the LLVM backend are:
a) FPC does not propagate type info down into the register level.  
There is no notion even of pointers, everything is just an integer of  
a particular size once it's inside a virtual register. The low level  
code generator routines are completely oblivious to the symbol table  
and high level type system (which in general is nice and helps modular  
design, but it's not nice in this case). It would be possible to  
simply typecast these integers to i8*/i16*/i32*/i64*/... when loading/ 
storing a value and forgetting about it for the rest, but I'm not sure  
to what extent that affect LLVM's ability to generate good code (and  
since getting better code is the whole point...). It would also be  
possible to implement the LLVM code generation at a higher level  
(bypassing the low level code generator, and directly translating the  
parse tree nodes into LLVM byte code), but that would both be a lot of  
work, and mean that any code generation fix or addition would need to  
be implemented twice.
b) the code generator currently does not support CPUs where the size  
of the integer registers is > sizeof(pointer). I've worked a bit on  
trying to separate the sizeof(pointer) from sizeof(integer registers),  
but it's not complete (the {$ifdef cpu64bitaddr} vs {$ifdef  
cpu64bitalu} defines in the compiler).

Finally, there are also the i386 problems
- for Delphi compatibility, FPC's default calling convention on all  
i386 targets is "Borland fastcall", which is different from all other  
i386calling conventions (see http://en.wikipedia.org/wiki/X86_calling_conventions#Borland_fastcall 
  ). And you'd be surprised how much code is out there that depends on  
this (even our RTL won't work without this, a.o. the signal handling  
depends on this). So at least for i386, LLVM would first need support  
for this calling convention.
- I'm also not sure whether or not LLVM has support for the x87  
extended floating type in the mean time (80 bits floating point),  
another requirement for our i386 port. Other cpu targets are more  
standard though, and should not pose such problems.


Jonas