RFR(S): 8243670: Unexpected test result caused by C2 MergeMemNode::Ideal

[Nils Eliasson]

Hi,

I second Tobias. How often is this code path triggered? Would this be 
removing an optimization that is important is some cases?

If this is extremely rare - I would be ok to remove it, otherwise we 
should evaluate Tobias suggestion.

Best regards,
Nils

On 2020-05-26 16:23, Tobias Hartmann wrote:
> Hi Felix,
>
> thanks for the details, makes sense to me.
>
> Isn't the root cause that we are loosing type information and wouldn't that be solved by selecting
> the Phi with the more restrictive _adr_type?
>
> Best regards,
> Tobias
>
> On 07.05.20 15:42, Yangfei (Felix) wrote:
>> Hi Tobias,
>>
>>> -----Original Message-----
>>> From: Tobias Hartmann [mailto:tobias.hartmann at oracle.com]
>>> Sent: Thursday, May 7, 2020 5:10 PM
>>> To: Yangfei (Felix) <felix.yang at huawei.com>; hotspot-compiler-
>>> dev at openjdk.java.net
>>> Subject: Re: RFR(S): 8243670: Unexpected test result caused by C2
>>> MergeMemNode::Ideal
>>>
>>> Hi Felix,
>>>
>>> were you able to figure out how we ended up with two Phis with same input
>>> but different _adr_type?
>> As I remembered, there are two major transformations which leads to this:
>>
>> 1. During Iter GVN1, a new phi is created with narrowed memory type through PhiNode::slice_memory.
>>      The new phi and the old phi have different _adr_type and different input.
>>
>> 2. Then C2 peel the first iteration of the given loop through PhaseIdealLoop::do_peeling.
>>      After that, the new phi and the old phi have same input but different _adr_type.
>>
>> Hope this helps.
>>
>> Thanks,
>> Felix
>>