review (S) for 6984979: OptimizeFill misses some cases with an odd memory graph

[Vladimir Kozlov]

Looks good.

Vladimir

Tom Rodriguez wrote:
> I don't think it's possible for it to be structured any other way, but I can add that check to the initial sanity check of the store.  I've updated the webrev.
> 
> tom
> 
> On Sep 15, 2010, at 2:41 PM, Vladimir Kozlov wrote:
> 
>> Tom,
>>
>> Should we also check that n->is_Phi() && n->in(LoopNode::LoopBackControl) == store?
>>
>> Thanks,
>> Vladimir
>>
>> Tom Rodriguez wrote:
>>> http://cr.openjdk.java.net/~never/6984979
>>> 6984979: OptimizeFill misses some cases with an odd memory graph
>>> Reviewed-by:
>>> The logic for the new OptimizeFill code misses a case where the Phi
>>> usage is different than expected.  Sometimes during transformation of
>>> the loop there are uses of the memory phi outside the loop.  This
>>> appears to be a valid though slightly surprising structure but it
>>> interferes with the fill matching logic that assumes the store in the
>>> loop should be the only outgoing state.  The fix is to allow the phi
>>> to be used outside the loop and replace it with the outgoing memory of
>>> the call to the fill.  Tested with jbb, runthere and ctw.
>