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@gmail.com