inside the GHC code generator

[Kevin Glynn]

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:
 > http://www.cs.mu.oz.au/research/mercury/download/gcc-backend.html
 > http://gcc.gnu.org/frontends.html
 > 
 > 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:

  http://www.cs.mu.oz.au/research/mercury/information/papers.html#hlc_cc

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 ...

k