Re: Third party compiler middle and back-end

On Tue, 19 Oct 2010 18:07:57 +0100, Philip Herron
<redbrain@gcc.gnu.org> wrote:


>On 12 October 2010 20:46, George Neuner <gneuner2@comcast.net> wrote:
>
>> LLVM is much superior to GCC if you want to understand what's going on
>> in the guts of your compiler. LLVM is not as mature as GCC and does
>> not yet do some of the more involved technical analyses, but it's IR
>> and code generator passes are cleanly delineated and are pretty easy
>> to figure out.
>
>i think the reason LLVM has become so popular for lang designers in
>my opinion because there is just such vast internals documentation
>compared to GCC.


I think the documentation overall is fairly comparable, but IMO the
GCC documentation is harder to read.


People use to joke about the five volumes of Inside Macintosh: it was
said that to understand any one of them you first had to understand
the other four. The GCC documentation is like that.


see http://gcc.gnu.org/onlinedocs/gccint/


In my opinion, the reason LLVM has become popular is because of its
extreme modularity which allows developers to more easily pick and
choose which algorithms they want to employ.




>I personally don't like LLVM its very pushed towards you _must_ you
>its internals to even do things like your own parser etc. Yes its not to
>say you cant implement your own and have some code to transform it
>into what LLVM speaks.


LLVM provides a library for building and manipulating the IR. You can
use any parser tool and have it build the IR directly.




>I wouldn't say LLVM would be superior


If you look at the top of this post you'll see my comments reprised.


LLVM is still being developed. For the moment GCC has available more
sophisticated analyses and possible optimizations. If you need them,
then GCC is the way to go.


But I expect that LLVM will catch up eventually. And as with GCC, the
LLVM developer encourage users to contribute new modules to the
project.




>I think everyone has the old GCC in mind but i personally think its
>changed alot from what it used to be.


I was and am talking about GCC v4. Older versions of GCC were a
nightmare of conditional spaghetti that I wouldn't wish on an enemy.
[Ok, maybe on an enemy 8-]




>I think someone made the point that GCC pushes code generation to be
>geared towards procedural languages and it isn't very dynamic.


That was me. GCC was designed to be a common back-end for several
popular procedural languages and it does not handle other models very
well.


Which is not it can't be used for other programming models, but the
code must be converted into procedural form before GCC can work with
it. The farther the language from procedural, the more performance
may be lost in the conversion.


As I said in another post, almost anything can be converted to C.




>well i am implementing python on it i wish i had more time at the moment


Apart from the dynamic environment - which is a runtime issue - Python
still is mainly a procedural language. The little shades of
functional model can be handled easily by lambda lifting or CPS
transformation.


Try implementing a declarative or data-flow model on it and you'll
quickly find out how demanding GCC is of procedural input.


George

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