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 _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
