inside the GHC code generator

[Rene de Visser]

>seems that you don;t understand the situation. ghc compiles Haskell to
>language called "core", do almost all optimizations at level of this
>language, then translates final result to the "STG" language from that
>the C-- code is generated. changing the translation of STG can't
>prevent ANY ghc optimization. although iy is not so easy because ghc
>code generation and RTS closely tied together

I should have been a bit clearer here. I meant that optimizations that are 
available from
STG -> Assembler, are better than STG -> C -> Assembler.

GHC currently doesn't do most of the optimizations I am thinking of.
-- Bit tagging to reduce pointer chasing, speed up pattern matching. Due to 
memory latency and speed it is quicker to do bit masking rather than memory 
reads
-- Parameter passing and regisgter usage opimizations that rely on the 
structure of the RTS.
-- Multiple stacks with custom frame layout.
-- dynamic code optimization etc.
-- Taking advantage of special assember instructions and flags.

Though I have also seen comments that you can do a lot of these with GCC if 
you do your own stack and parameter management. i.e. don't use the C stack 
at all.

Though your suggestions are probably better than nothing, which is probably 
what the alternative is (for instance I have not sufficient time to work on 
these things).

Note that I didn't say that the assembly generation of OCAML was better than 
GCC, just that it was comparable.

Rene.