----- Original Message ----
> From: Jonas Maebe <jonas.ma...@elis.ugent.be>
> To: FPC developers' list <fpc-devel@lists.freepascal.org>
> Sent: Wed, November 11, 2009 5:03:52 AM
> Subject: Re: [fpc-devel] LLVM Backend?
>
>
> On 11 Nov 2009, at 04:29, Samuel Crow wrote:
>
> > As noted in other messages on the list, the LLVM-FPC compiler would be
> > heavily
> dependent on LLVM and, in turn, would require newer operating system support
> for
> the compiler to run on MacOSX 10.4, for example, (primarily because of the
> linker and debugger situation on the earlier models' XCode versions) since
> that's the earliest that LLVM supports. I have a 10.3.9-based PowerMac G4
> that
> we could test the resultant code on, but I'm not holding my breath to think
> that
> it will work.
>
> In a sense it's no problem if the LLVM backend doesn't support all targets
> that
> the other backends support, after all it'll be just another choice that
> people
> can use. I just want to avoid the LLVM backend being completely disconnected
> from the other backends or require an inordinate amount of maintenance to
> keep
> it in sync with the other backends, because in that case it would probably be
> quite short-lived (unless some dedicated maintainer would step up and
> constantly
> keep it in sync with the rest).
>
What I originally had in mind was to use the LLVM support classes based on C
bindings for libstdc++ and LLVM's template libraries. See
http://llvm.org/docs/ProgrammersManual.html for LLVM's best practices. So, as
such, it wouldn't be entirely disconnected from the rest of the project. It
would just be another LLVM frontend. As for the code maintenance, the
Mattathias BASIC team would be using the code for our compiler in the future as
well so we'd have to protect it from bitrot. Unfortunately something so
drastic would be like a fork of the project and I like the fact that FPC will
work on my old PowerMac G4 as well as the newer systems. I was also hoping to
avoid having to write our compilers as GCC frontends as well since that
framework is poorly documented.
> > I think the runtime library and frontend parser would be needed more than
> > the
> rest of the FPC compiler itself. Most of the backend and intermediate code
> in
> the FPC optimizer would be redundant with LLVM.
>
> As I see it, there are basically two approaches to integrate a compiler with
> LLVM:
> a. the LLVM-GCC approach, where you bolt an existing compiler's frontend onto
> llvm
> b. the dragonegg approach (http://dragonegg.llvm.org/), where you make use of
> the support in an existing compiler (again GCC in this case) for abstract
> code
> generator support to emit LLVM assembler/bitcode rather than machine code
>
> I am very much in favour of approach b, because I think it's the only one
> that
> can stand the test of time (in case a, you you constantly have to keep your
> "bolts" up-to-date as the frontend evolves).
>
> FPC already has a fairly abstract code generator interface, because we don't
> use
> intermediate code: parse tree nodes are translated into machine code by
> calling
> the appropriate code generator class methods. The existing abstract code
> generator's interface is lower level than LLVM's as far as the type info is
> concerned though, so we need a higher level (either sitting above the current
> code generator, or replacing existing code generator).
>
We may want to replace the existing code generator, unfortunately. The reason
that LLVM requires such high-level code for the calling routines is that it
supports not only different calling conventions but it promotes from the
stack-based C calling convention to a register-loaded fastcall convention
whenever possible. This may not have been necessary when using the Borland
Fastcall convention but sometimes being able to rearrange the registers when
calling different functions can avoid some spillage to the stack.
I think the biggest obstacles to using LLVM at this point is that Borland
Fastcall isn't supported by the x86 backend for LLVM and that the type
information isn't high-level enough in the FPC compiler. That's two problems,
both fairly significant (although the latter is definitely heavier than the
former). Do you think it's too soon to divide out the work? Is there more
that needs discussion?
Let me know what you think.
--Sam Crow
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
