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

[Simon Marlow]

On 23/03/2011 13:48, Edward Z. Yang wrote:
> 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'm surprised by this - we ought to look into why it isn't doing a beter 
job here.  Do you have a small example?

Cheers,
	Simon


> 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.
>
> _______________________________________________
> Cvs-ghc mailing list
> Cvs-ghc at haskell.org
> http://www.haskell.org/mailman/listinfo/cvs-ghc