On 11 Nov 2009, at 04:29, Samuel Crow wrote:
The IRBuilder class http://llvm.org/doxygen/classllvm_1_1IRBuilder.html is as stable as the instruction set it builds and is maintained as such since it is used by Clang, LLVM-GCC and other frontends.
Ok, that would be fine then. The only problem is actually interfacing with the C++ classes then, because as mentioned that's not supported currently.
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).
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).
The reason I'm not afraid to redo most of the internals of FPC is that I am involved in a compiler project already and would need to reuse the code for that project also. Before I noticed that there was an LLVM backend already started for FPC I was going to take the parser description from the documentation and start from scratch anyway.
As mentioned before, I do not think the end result of such an approach would be sustainable in the long term (unless all code generators would be removed in favour of the LLVM backend, but I don't see that happening for a variety of reasons).
I'm looking forward to the challenges of this project. I hope I haven't scared you all with my brashness (and yes I am a little crazy also). I'll talk to you more later.
Thanks for your interest! Jonas _______________________________________________ fpc-devel maillist - [email protected] http://lists.freepascal.org/mailman/listinfo/fpc-devel
