RFR(S): 8243670: Unexpected test result caused by C2 MergeMemNode::Ideal
Tobias Hartmann
tobias.hartmann at oracle.com
Tue May 26 14:23:39 UTC 2020
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
>
More information about the hotspot-compiler-dev
mailing list