[9] RFR(S): 8174164: SafePointNode::_replaced_nodes breaks with irreducible loops

[Vladimir Kozlov]

Hmm, may be you are right. I was thinking about value numbering due to 
the same hash value. But to have the same hash the input should be the 
same and it should be replaced in caller already as you said. May be 
different branch? But then has includes control edge too.

Then in what cases your new check (_idx >= idx) fails?

Vladimir

On 2/9/17 11:31 AM, Roland Westrelin wrote:
>
>> The scenario I am concern with is next. Assuming that replacement
>> happened in callee, for example, due to class check where one branch
>> will go into UNC Trap. But at the same time node representing klass
>> constant (CheckCastPP) is already present in caller (used for an other
>> not related nodes). As result you will get 'improved' node as old node
>> and it will not pass your new condition. So what happens in such case?
>> Will we able to make replacement?
>
> If the CheckCastPP is in the caller, then replace_in_map replaces the
> input of the CheckCastPP with the CheckCastPP in the caller's map. That
> improvement is done before the callee is called so is valid in the
> callee too. When parsing exits the callee, no replacement happens
> (CheckCastPP is not a new node in the callee) but there shouldn't be any
> to do because replace_in_map already modified the caller's map before
> the callee was parsed. When parsing exits the caller, replacement
> happens in the caller's caller map (the CheckCastPP is a new node). So
> the caller's caller, the caller and the callee should all see the
> improved nodes, right?
>
> Roland.
>