darcs patch: Immediately tag initialization code to prevent untagge...
Edward Z. Yang
ezyang at MIT.EDU
Wed Mar 23 14:48:37 CET 2011
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
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
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.)
> 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.
More information about the Cvs-ghc