[fpc-devel] LLVM Backend?
jonas.maebe at elis.ugent.be
Tue Nov 10 22:46:59 CET 2009
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
> 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.
More information about the fpc-devel