inside the GHC code generator
Rene de Visser
rene_de_visser at hotmail.com
Thu Feb 23 09:32:21 EST 2006
>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
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
-- 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
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
Note that I didn't say that the assembly generation of OCAML was better than
GCC, just that it was comparable.
More information about the Glasgow-haskell-users