Thanks,
Next stop is to look into whether we can do some simple peep-hole
optimisation and instruction reordering, though I'm not sure how many
opportunities there are in GHC code just yet.
I had originally thought that doing instruction reordering might be a
big win because the T2 is an in-order processor. However, I've been
reading the micro architecture manual, and the pipeline seems to have a
substantial set of bypass-paths that might already deal with that problem.
I'll have to do some more testing against GCC compiled code, and ask
Darryl about it. I'll post the result when they're done.
Ben.
Norman Ramsey wrote:
> Sat Feb 14 21:51:58 PST 2009 [email protected]
> * NCG: Split up the native code generator into arch specific modules
Ben,
This is great news! I am eager to have a look at the code,
maybe on March 3 :-)
We are really hoping that the ZipCfg data structure will be useful in
the arch-specific NCG modules. Right now there's an ugly violation of
modularity; StackInfo has to be scrubbed out of the ZipCfg data
structure. I would definitely like to work on this and see if we can
make it useful to the back ends. It would also be nice to see if
there are opportunities for peephole optimization based on John's
work.
Norman
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
