review (S) for 6984979: OptimizeFill misses some cases with an odd memory graph
tom.rodriguez at oracle.com
Wed Sep 15 16:30:36 PDT 2010
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.
On Sep 15, 2010, at 2:41 PM, Vladimir Kozlov wrote:
> Should we also check that n->is_Phi() && n->in(LoopNode::LoopBackControl) == store?
> Tom Rodriguez wrote:
>> 6984979: OptimizeFill misses some cases with an odd memory graph
>> 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.
More information about the hotspot-compiler-dev