[13] RFR (S): 8161334: C2: Cast nodes hinder memory alias analysis

[Vladimir Ivanov]

Thanks, Vladimir.

Best regards,
Vladimir Ivanov

On 14/02/2019 15:29, Vladimir Kozlov wrote:
> Sorry, I misread the code. NM.
> 
> Changes are good.
> 
> Thanks,
> Vladimir
> 
> On 2/14/19 1:48 PM, Vladimir Ivanov wrote:
>>
>>> Should you also take into account casts in following Allocation 
>>> checks at line #1072?
>>
>> Are you asking about the following?
>>
>> 1069     // A load from a freshly-created object always returns zero.
>> 1070     // (This can happen after LoadNode::Ideal resets the load's 
>> memory input
>> 1071     // to find_captured_store, which returned 
>> InitializeNode::zero_memory.)
>> 1072     if (st->is_Proj() && st->in(0)->is_Allocate() &&
>> 1073         (st->in(0) == ld_alloc) &&
>> 1074         (ld_off >= 
>> st->in(0)->as_Allocate()->minimum_header_size())) {
>>
>> st is a memory, so I don't see how (Check)CastPP can be seen there.
>>
>> Best regards,
>> Vladimir Ivanov
>>
>>> On 2/12/19 2:32 PM, Vladimir Ivanov wrote:
>>>> http://cr.openjdk.java.net/~vlivanov/8161334/webrev.00/
>>>> https://bugs.openjdk.java.net/browse/JDK-8161334
>>>>
>>>> The following IR is produced for the slow case reported in the bug:
>>>>
>>>>    B = CastPP (DecodeN ...)                   // ...$C:NotNull
>>>>    S = StoreI M (AddP (            B) #off) V // ...$C:NotNull
>>>>    L = LoadI  S (AddP (CheckCastPP B) #off)   // ...$C:NotNull:exact
>>>>
>>>> MemNode::can_see_stored_value() can't prove S & L access the same 
>>>> location since AddPs are different (since base nodes differ). 
>>>> There's a special case there, but only when Allocate is a base.
>>>>
>>>> Proposed patch generalizes existing Allocate case to the case when 
>>>> both base & offset are known to be the same.
>>>>
>>>> Testing: hs-precheckin-comp, tier1-5
>>>>
>>>> Best regards,
>>>> Vladimir Ivanov