Re: [fpc-devel] LLVM Backend?
Hi Jonas, - 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! Also, as part of the Mattathias BASIC project, our team leader has almost completed the LLVM-PEG utility for implementing parsing expression grammars in LLVM Assembly. If I end up continuing the work I started on a new LLVM-FPC parser I'll be using that as my tool of choice and implementing the code sections with support routines from LLVM and Clang. (I won't have the liberty of using Clang's libraries in the BASIC compiler since BASIC requires a two-pass compilation process.) That's quite an undertaking! 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. I hope your workload permits you to work on the function calling mechenism soon. Thanks for your advice. 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. Thanks for your help, --Sam ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LLVM Backend?
Hello Michael, The MIPS32 code for LLVM's code generator is out-of-date but salvageable. If you're familiar with C++ I'd recommend anybody use LLVM for its massive optimizations, documentation and support classes. If you want C/C++/Objective C compiler as well as other compilers working on your processor, LLVM would certainly be worth it. If, on the other hand, you want only a Pascal compiler and don't care about the other languages, it is too soon to tell. LLVM-FPC is still in its infancy. I wish I could give you a more certain answer. The best I can tell you is this: If and when the softcores at Natami.net become available commercially, I will probably be making an LLVM backend for the 68050 rather than using the existing GCC backend for the 680x0 even though I program in C++. Does that answer your question? --Sam Crow - Original Message From: Michael Schnell mschn...@lumino.de To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Wed, November 11, 2009 4:56:52 AM Subject: Re: [fpc-devel] LLVM Backend? Samuel Crow wrote: I'm looking forward to the challenges of this project. I am planing for another project: doing an FPC compiler for the NIOS processor (which is similar to MIPS32) on a Linux target. Do you think it's viable to consider LLVM instead of trying to modify the native ARM FPC code generator ? -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LLVM Backend?
- 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
Re: [fpc-devel] LLVM Backend?
- Original Message From: Jonas Maebe jonas.ma...@elis.ugent.be To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Wed, November 11, 2009 1:43:08 PM Subject: Re: [fpc-devel] LLVM Backend? -snip- 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? It's not entirely clear to me yet how you see the result: an FPC frontend added to the LLVM project, or an LLVM backend added to the FPC project. I favour the latter, but a lot of what you talk about seems to be about the former. Or am I misunderstanding things? I think you are understanding things well. I'm looking to FPC as a means to an end where having a team member on the Mattathias BASIC team is creating some libraries in Delphi that I want ported to LLVM. The reason I haven't thought through the Pascal-specific portions of the task is that I am a C++ programmer. The last time I programmed in Turbo Pascal, Delphi didn't even exist. My first C programming class in college back in 1994 was on Turbo C++. I've since gone on to do a lot of stuff in C and a little stuff in C++. I still have my Turbo Pascal textbook but it's so out-of-date with regards to OOP that it is useless to me. I am unable to parse half the stuff I see when I look at modern FPC source. Perhaps rather than discuss what code we will use from which project, FPC or LLVM, we should be talking about who wants to do what. If I am to do most of the work, then the packed array of booleans will be implemented with an LLVM bitvector template class on a thin Pascal frontend accessing most of its code through C wrappers of C++. If you do it, we'll be using a Pascal array of packed booleans properly in Pascal and I wouldn't know what difference it would make. If packed arrays apply to non-boolean types, and I'd be none-the-wiser as to how it worked apart from my 1994-vintage Turbo Pascal programming knowledge and my knowledge of programming in 68020 Assembly. As far as code-maintenance is concerned, I favor LLVM code over FPC code because as long as I watch the mailing list and rewrite portions of the code, it will be an out-of-sync version of Pascal that would do what I needed it to do in much the same way as FPC is out-of-sync with my old Amiga computer's backend. I don't plan on bringing the Amiga backend up-to-date but I do plan on writing a backend for the 680x0 series processors on LLVM for use with Mattathias BASIC. In summary, herein lies the source of our disagreement: I want to work in C++ because it is what I know. You want to work in Pascal because it is what you know. We need to divide out the work so that we each know what is expected of us. Does that answer your questions? --Sam Crow ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LLVM Backend?
- Original Message From: Jonas Maebe jonas.ma...@elis.ugent.be To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Wed, November 11, 2009 3:41:22 PM Subject: Re: [fpc-devel] LLVM Backend? Yes, it does, thanks. The main problem I see is that my approach would require a lot of initial work from my part (creating the high level code generator that could call through to LLVM libraries), so a) you'd be pretty much blocked until that work were finished if you'd go with that approach b) I honestly have no idea how soon I could finish that (or even how soon I could seriously get going in doing that) Alright Jonas, I can work on getting Borland Fastcalls implemented in the LLVM x86 backend. By the time I'm done with that we can talk about what else needs doing. Is there a test already in the FPC repository that I can use as a test to make sure that the calling convention is working? I'll be working on a MacOSX 10.5 Intel computer if that makes a difference. Also, as part of the Mattathias BASIC project, our team leader has almost completed the LLVM-PEG utility for implementing parsing expression grammars in LLVM Assembly. If I end up continuing the work I started on a new LLVM-FPC parser I'll be using that as my tool of choice and implementing the code sections with support routines from LLVM and Clang. (I won't have the liberty of using Clang's libraries in the BASIC compiler since BASIC requires a two-pass compilation process.) I hope your workload permits you to work on the function calling mechenism soon. Thanks for your advice. --Sam Crow ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] LLVM Backend?
Hello, 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. 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. 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. --Sam Crow ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LLVM Backend?
Hello Jonas,
(Replies inline.)
- Original Message
From: Jonas Maebe jonas.ma...@elis.ugent.be
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Tue, November 10, 2009 1:57:03 PM
Subject: Re: [fpc-devel] LLVM Backend?
-snip-
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).
The current way to implement pointer arithmetic in LLVM is to use an i64 for
all instances of pointers 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. 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.
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).
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.
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.
Normally, I think it is generated in SSE format using vector intrinsics.
Now I've got 2 questions for you:
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.
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.
Thanks for your time and consideration,
--Sam Crow
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LLVM Backend?
Hello again Jonas, - Original Message From: Jonas Maebe jonas.ma...@elis.ugent.be To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Tue, November 10, 2009 3:46:59 PM Subject: Re: [fpc-devel] LLVM Backend? -snip- 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. If you want to search the LLVM-Dev mailing list and you are behind on the emails, http://old.nabble.com/LLVM---Dev-f692.html seems to be the best way to do it. It is a searchable forum frontend for the mailing list. This should bring you up-to-date. I'll reply to the rest of the posts in separate messages. --Sam Crow ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
