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

[Vladimir Kozlov]

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