Re: [fpc-devel] LLVM Backend?

[Jonas Maebe]

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

----- Original Message ----

From: Jonas Maebe <jonas.ma...@elis.ugent.be>
To: FPC developers' list <fpc-devel@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!

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

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

tcc.c
Description: Binary data

tgdbcc.pp
Description: Binary data

tgdbcc.s
Description: Binary data

_______________________________________________
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel