inside the GHC code generator
glynn at info.ucl.ac.be
Thu Feb 23 13:06:25 EST 2006
Claus Reinke writes:
> > the long answer is: are you ever heard promises that gcc is best
> > cpu-independent assembler? no? and you know why? because gcc is not
> > cpu-independent assembler. gcc was strongly optimized to make
> > efficient asm from the code usually written by the C programmers. but
> > code generated by ghc has nothing common with it. so we are stay with
> > all these register-memory moves, non-unrolled loops and all other
> > results of naive compilation. gcc is just don't know how to
> > efficiently manage such code!
> would there be any advantage to targetting gcc's backend directly?
> I notice that Mercury seems to support this:
> that is, does using C as assembler disable possible optimizations,
> or is going through the C frontend enabling more optimizations than
> going to the backend directly?
On a related point, Mercury has two C backends a low level one at the
level of GHC's and a high level one. Bulat might want to read this for
a description of the high level C implementation:
Also, ghc used to be faster than gcc for a naive, recursive factorial
function (once the cpr analysis and optimisation was added). From
what Bulat wrote it seems that gcc got better ...
More information about the Glasgow-haskell-users