[fpc-devel] LLVM Backend?

[Jonas Maebe]

On 12 Nov 2009, at 18:15, Samuel Crow wrote:

> ----- Original Message ----
>> From: Jonas Maebe <jonas.maebe at elis.ugent.be>
>> To: FPC developers' list <fpc-devel at lists.freepascal.org>
>> Sent: Thu, November 12, 2009 7:48:58 AM
>> Subject: Re: [fpc-devel] LLVM Backend?
>>
>>
> -snip-
>> It does make a difference. Unfortunately. While working on a patch  
>> to add
>> Borland fastcall support to GDB, I discovered that there's a bug in  
>> our
>> implementation of Borland fastcall on Mac OS X (although I'm still  
>> not sure
>> why). I'll try to fix it tonight and create a test file that you  
>> can use.
>
> Thanks!

Seems like it was my code for GDB under Mac OS X that was wrong, not  
FPC. Borland fastcall is handled fine under Mac OS X. I've attached  
the test I've created.

To compile:
gcc -o tcc tcc.c tgdbcc.s -arch i386

The tcc.c file already includes a test for on of the two functions  
(and I've verified that it passes if the Pascal functions are compiled  
with C calling conventinos), but not yet for the other one. They mix a  
bunch of different parameters, which should provide a good start. I  
just noticed that I forgot to add in floating point parameters. They  
are passed in on the stack, and returned in st(0) (regardless of the  
precision). 80 bits extended is passed in a 12 byte location.

The details of the parameter passing are decided in http://svn.freepascal.org/svn/fpc/branches/release_2_2_4_rc1/compiler/i386/cpupara.pas 
. In particular, check out ti386paramanager.push_addr_param  
(determines whether a parameter is passed by address or by value),  
ti386paramanager.create_funcretloc_info (function return location) and  
ti386paramanager.create_register_paraloc_info (creates the actual  
parameter and return value locations). The internal compiler  
identifier for this calling convention is pocall_register.

The Pascal test file has been compiled with DWARF debug info. It's  
been manually stripped down from what the compiler produced to remove  
dependencies on the RTL.

> LLVM does most of the work with its support routines but I expect  
> that once we get the core language support in (including the ability  
> to extend the language), users will help with writing a few  
> extensions themselves.

Well, just like you prefer writing in C++, most of ours prefer  
Pascal :) Anyway, we'll see (and it would be nice to get an idea of  
the kind of performance gains we could get from an LLVM backend).

>> Even once this is finished, how do you propose we pass type  
>> information from FPC
>> to LLVM libraries? Via strings in LLVM assembler format? (since  
>> I've already
>> written that code) Or another way?
>
> There are classes to create any type documented at http://llvm.org/docs/ProgrammersManual.html#Type 
>  .  As of the current 2.6 release there are now more extensive C  
> bindings included with LLVM than were previously available.  Once I  
> get the trunk downloaded I'll see about a link to the actual  
> documentation on how to use those C bindings.

Ok.


Jonas

-------------- next part --------------
A non-text attachment was scrubbed...
Name: tcc.c
Type: application/octet-stream
Size: 1455 bytes
Desc: not available
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20091112/caec8aad/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tgdbcc.pp
Type: application/octet-stream
Size: 691 bytes
Desc: not available
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20091112/caec8aad/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tgdbcc.s
Type: application/octet-stream
Size: 16969 bytes
Desc: not available
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20091112/caec8aad/attachment-0002.obj>