Validate failures on the new codegen
Edward Z. Yang
ezyang at MIT.EDU
Thu Apr 7 19:45:59 CEST 2011
Excerpts from Karel Gardas's message of Thu Apr 07 13:14:46 -0400 2011:
> OK! Thanks for the information. So this -fnew-codegen is this famous
> codegen which is using hoopl for data-dependency tracking or something
> like that if I understand correctly
> And which is producing just C-- in order to be compatible with the current
> infrastructure, i.e. NCG?
Not quite. We have two C-- representations, in cmm/CmmNode.hs and cmm/OldCmm.hs
respectively. Our backends consume OldCmm, and Hoopl consumes CmmNode, and then
converts it to OldCmm using CmmCvt.hs.
> If I also read correctly somewhere on GHC Trac Wiki, then this -fnew-codegen
> should sometime in the future even replace NCG. May I ask you when such
> replace is planed?
That's the idea, but depends on how long it takes for us to get the new
code generator generating as good (or better--that's the idea behind
Hoopl) as the old code generator at a reasonable pace. The new codegen
is already several years into the making.
> I'm asking since I'm still poking with the idea of writing NCG for some GHC
> not yet supported platform and since this will be my free time hobby project
> it'll certainly take some time hence I do have doubts if to use current NCG
> as a basis for it or wait and/or use your new planned infrastructure.
It's certainly a question. Since we can convert from one to another, whichever
one you pick, we should be able to support (some fiddling may be required
if you use the new C-- representation, since none of our other backends use it
right now--but this is certainly the way forward.)
More information about the Glasgow-haskell-users