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