inside the GHC code generator

[Bulat Ziganshin]

Hello Rene,

Thursday, February 23, 2006, 5:32:21 PM, you wrote:

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

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

theoretically - yes. in practice, it is hard to compete with gcc. ghc
wait for such code generation 15 years (wait for the mountain to go in
our direction :) and i think that the REAL way to reach gcc level
optimization is to compile to the idiomatic C instead of continue
waiting while this theoretically possible optimization will arise

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

i think that all these things can be done with "idiomatic C" way

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

as i see in the current code generation, attaempts to do our own
stack management lead to that gcc just don't understand such code and
don't optimize it as good as possible. please compare code generated
for fac() function with all other variants

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

moreover, i sure that you can't compete with gcc :)

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

what mean "comparable"? and what we should do to reuse this code
generation in ghc? at least i know what to do to reuse gcc code
generation. can you propose similar plan to reuse ocaml code
generation?


-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin at gmail.com