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

[Tom Rodriguez]

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.