Re: Third party compiler middle and back-end

On Wed, 13 Oct 2010 13:46:50 -0700, "BGB / cr88192"
<cr88192@hotmail.com> wrote:


>for GCC, I much prefer the overall process, since it is more solidly divided
>into layers and representational stages (nevermind if one wants to
>understand how the code itself works, as least they know that it takes a
>certain input and produces a certain output). takes GIMPLE, produces GAS
>(nevermind what happens internally...).
>
>LLVM seems to be a bit more winding and a bit more object-centric from what
>I have seen (so, it is more like dealing with a lot of object-plugging,
>rather than dealing with layered data filters/transforms, and one has to
>look at a bunch of different classes to understand how things fit together).


Well, GCC and LLVM have very different philosophies. The developer
interacts with LLVM at a much lower level than is typical with GCC.


GCC mainly is designed to be a common back-end. It provides
monolithic modules which essentially are meant to be used (or not) "as
is". Most projects using GCC only ever replace the front-end parser
or back-end code generator. GHC is the only project I know of which
made extensive modifications to the middle.


In contrast, LLVM is designed as a toolkit. It provides common IR
data structures and methods to work with them, and a collection of
library modules, each of which implements just one high level
"function", and which are meant to be composed and strung together as
needed by the compiler developer. LLVM was meant to be extended: it
provides skeleton code for creating new modules.




IMO the way GCC is structured limits its usefulness ... the middle IR
section is designed for procedural languages and it does not handle
very well any language that isn't mainly procedural. The developers
of Haskell rewrote large sections of the middle from scratch to
support Haskell's type model and lazy functional semantics. GHC still
is the only project I know of that has done this.


Turing equivalence guarantees that any language can be emulated in C,
and so technically GCC can support any language ... but the results
can be disappointing. It's been my observation that most compilers
for declarative languages - functional, logic, dataflow, etc. - have
not been based on GCC. And, AFAIK, no compiler for any pure OO
language is based on GCC.




>side note:
>I had looked at LLVM some before a few years back, but at the time it didn't
>do what I wanted or how I wanted things done (basically, converting directly
>from IR to machine code and putting machine code into executable buffers).
>there was no dynamic relinking, but instead a process of recompiling chunks
>of IR and patching up the prior versions of functions with jumps to the new
>version.


I haven't played very much with the JIT generators so I can't comment
much on this ... thus far I've mostly used LLVM for stand-alone
compilers. However, it permits quite low level, pass-by-pass control
of the compilation process - so I suspect that what you want to do is
possible.


LLVM has changed and grown quite a bit in the last few years so it
might be worth looking at it again.


The main point I'm trying to make here is that if you don't like how
it handles something, IMO it is much easier to change and extend LLVM
than it is GCC.


George

Return to the comp.compilers page.
Search the comp.compilers archives again.