RFR(S): 8069191: moving predicate out of loops may cause array accesses to bypass null check

[Roland Westrelin]

Thanks for looking at this.

> This is what I waited for long time! Thank you for doing this, Roland.
> 
> How you handle case when CastPP is input of Phi node?

The Phi has a control so any memory node that depends on the Phi output is guaranteed to be “after” the CastPP, right?

> I am worried how you separate cases when precedence edge added from CastPP and other precedence cases. Can you explain? May be there are no problems.

The

if (m->is_block_proj()) {

test guarantees that the precedence edge is a control node. And I assume it’s always ok to remove the precedence edge and adjust the control when the precedence edge is a control node. Do you think that could break something?

Roland.

> 
> Thanks,
> Vladimir
> 
> On 3/17/15 3:54 AM, Roland Westrelin wrote:
>> http://cr.openjdk.java.net/~roland/8069191/webrev.00/
>> 
>> In the test (that needs to be run with StressGCM to cause incorrect code generation), a dependency carried by a CastPP is lost when CastPPs are removed after CCP. Detailed description of the bug is in:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8069191
>> 
>> Vladimir suggested investigating the performance impact of keeping the CastPPs for the entire compilation. I found that this still causes performance regressions as documented in:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8039999
>> 
>> The fix I suggest is to keep CastPPs during optimizations and remove then during final graph reshaping. To not loose the dependencies they carry, precedence edges are added to memory operations that depend on them. During GCM, the control of the memory operations to take the current control and the precedence edges.
>> 
>> Experiments show that this scheme doesn’t cause performance regressions (I ran promotion testing on x64 and sparc).
>> 
>> Roland.
>>