review for 7032963: StoreCM shouldn't participate in store elimination
Vladimir Kozlov
vladimir.kozlov at oracle.com
Fri Apr 1 17:15:31 PDT 2011
And, it seems, your current code covers this case already. So my false
assumption helped you to find the real problem ;)
Thanks,
Vladimir
Vladimir Kozlov wrote:
> Actually I thought about slightly different case:
>
> a.f = x
> if (test) {
> a.b = y;
> }
>
> But StoreCM for a.f should have several users (StoreCM for a.b and
> mergemem) so your condition (stop serch if multiple users) stays true.
>
> Vladimir
>
> Tom Rodriguez wrote:
>> On Apr 1, 2011, at 4:37 PM, Vladimir Kozlov wrote:
>>
>>> An other problem if n is on a branch and you could eliminate
>>> dominated StoreCM which above the split point resulting in not having
>>> StoreCM on opposite branch.
>>
>> You mean:
>>
>> a.f = x
>> b.f = y;
>> if (test)
>> return
>> a.b = c;
>>
>> The StoreCM for a.f has a single user but it's used by the StoreCM of
>> b.f which has multiple users. So I think the search needs to stop
>> when it encounters multiple users of a StoreCM since that represents a
>> split of control flow. Thanks for catching that.
>>
>> Sounds like a job for partial redundancy elimination.
>>
>> tom
>>
>>> Vladimir
>>>
>>> Tom Rodriguez wrote:
>>>> On Apr 1, 2011, at 3:47 PM, Vladimir Kozlov wrote:
>>>>> You may put n->in(MemNode::Address) and n->in(MemNode::ValueIn)
>>>>> into locals before the loop. Also you need to kill the node
>>>>> explicitly otherwise it still be connected to its inputs:
>>>>>
>>>>> + // Eliminate the previous StoreCM
>>>>> + prev->set_req(MemNode::Memory, mem->in(MemNode::Memory));
>>>>> + assert(mem->outcnt() == 0, "should be dead");
>>>>> + mem->disconnect_inputs(NULL);
>>>> I'll have to rework the mem traversal a little. Actually I think
>>>> there might have been a bug with the old code since it always
>>>> updated prev. I believe this is correct:
>>>> // Eliminate the previous
>>>> StoreCM
>>>> prev->set_req(MemNode::Memory, mem->in(MemNode::Memory));
>>>> assert(mem->outcnt() == 0, "should be dead");
>>>> mem->disconnect_inputs(NULL);
>>>> } else
>>>> {
>>>> prev =
>>>> mem;
>>>> }
>>>> mem = prev->in(MemNode::Memory);
>>>> }
>>>> I think I'll put together a little test case to make sure this is
>>>> working correctly.
>>>> tom
>>>>> Vladimir
>>>>>
>>>>> Tom Rodriguez wrote:
>>>>>> I could push this to hotspot-gc so it gets more CMS testing .
>>>>>> http://cr.openjdk.java.net/~never/7032963
>>>>>> 7032963: StoreCM shouldn't participate in store elimination
>>>>>> Reviewed-by:
>>>>>> StoreCM shouldn't participate in redundant store elimination since
>>>>>> that could violate the requirement that a StoreCM must be strictly
>>>>>> after a field update. This results in a large number of redundant
>>>>>> StoreCMs being emitted for blocks of fields updates, so I added an
>>>>>> optimization to fold them up safely. Previously the extra dependence
>>>>>> was converted into a precedence edge just before register allocation
>>>>>> but I moved this logic into final_graph_reshape. I then added logic
>>>>>> to search through chains of StoreCMs to eliminate earlier redundant
>>>>>> ones and transfer their precedence edges to the one that is kept.
>>>>>> This ensures that they are scheduled properly. This actually
>>>>>> eliminates duplicates that were previously missed so the code quality
>>>>>> is slightly better. Tested by inspecting code generation with script
>>>>>> to identify duplicates. Also ran CTW with -XX:+UseCondCardMark and
>>>>>> -XX:+UseG1GC.
>>
More information about the hotspot-compiler-dev
mailing list