darcs patch: Immediately tag initialization code to prevent untagge...

[Edward Z. Yang]

I made a different change, which, with constant folding, should be just as
good: allocate a new register, so everything is kept in SSA.  I've sent
the updated patch.

One infelicity is that the inliner doesn't seem to manage to inline:

    Y = Hp + 4
    Z = Y + 1
    R1 = Z

into

    R1 = Hp + 5

it only manages:

    Z = Hp + 5
    R1 = Z

I suspect this will get fixed when we port the mini-C-- optimizer to use
Hoopl.

Edward

Excerpts from Edward Z. Yang's message of Tue Mar 22 10:09:20 -0400 2011:
> It occurs to me that this patch kind of generates stupid code when no
> tag bit is necessary: it does:
> 
>     abc = Hp + 4
>     abc = abc
> 
> So one minor adjustment would be to check if the tag bit is zero and
> omit the assignment.
> 
> Another possibility is to pattern match on the first expression and
> fold the extra offset in there (I didn't want to originally do this,
> but revisiting the code I think this might be eminently doable.)
> 
> Cheers,
> Edward
> 
> Excerpts from Edward Z. Yang's message of Sun Mar 13 11:02:58 -0400 2011:
> > 1 patch for repository http://darcs.haskell.org/ghc:
> > 
> > Sun Mar 13 14:54:29 GMT 2011  Edward Z. Yang <ezyang at mit.edu>
> >   * Immediately tag initialization code to prevent untagged spills.
> >   
> >   When allocating new objects on the heap, we previously returned
> >   a CmmExpr containing the heap pointer as well as the tag expression,
> >   which would be added to the code graph upon first usage.  Unfortunately,
> >   this meant that untagged heap pointers living in registers might
> >   be spilled to the stack, where they interacted poorly with garbage
> >   collection (we saw this bug specifically with the compacting garbage
> >   collector.)
> >   
> >   This fix immediately tags the register containing the heap pointer,
> >   so that unless we have extremely unfriendly spill code, the new pointer
> >   will never be spilled to the stack untagged.
> >   
> >   An alternate solution might have been to modify allocDynClosure to
> >   tag the pointer upon the initial register allocation, but not all
> >   invocations of allocDynClosure tag the resulting pointer, and
> >   threading the consequent CgIdInfo for the cases that did would have
> >   been annoying.