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

[Vladimir Ivanov]

> 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