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

Yep.

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

Edward



More information about the Glasgow-haskell-users mailing list