[15] RFR(M): 8242108: Performance regression after fix for JDK-8229496

[Tobias Hartmann]

Hi Eric,

thanks for looking at this!

On 21.04.20 06:12, Eric Liu wrote:
> I'm not sure whether you noticed that with https://bugs.openjdk.java.net/browse/JDK-8229496, the 'CastII/CastLL' would mislead GVN that make it unable to recognize the same 'CmpNode' as before.
> 
> E.g. for java code:
> ```
>         public int foo(int a, int b) {
>             int r = a / b;
>             r = r / b; // no need zero-check
>             r = r / b; // no need zero-check
>             return r;
>         }
> ```
> 
> The zero-check for 'b' could not be removed as before if 'b' is boxed with CastII.

Right and there are also some other problems (for example, CastLL does not implement the Value
optimizations that CastII has).

> I think backing out the original fix for 8229496 would solve this problem.

Yes, I've verified that.
> One comment:
> 
> The test case [1] try to detect the wrong dependency order but I assume it unable to find the same issue in AArch64 due to the different behavior of div/mod compared with AMD64.
>  
> [1] http://cr.openjdk.java.net/~thartmann/8229496/webrev.00/raw_files/new/test/hotspot/jtreg/compiler/loopopts/TestDivZeroCheckControl.java 

I'm not familiar with the div/mod implementation on AArch64 but the underlying issue, which is a
div/mod node floating above the null-check, is platform independent.

Thanks,
Tobias