RFR(XS): 8149543: range check CastII nodes should not be split through Phi
Vladimir Kozlov
vladimir.kozlov at oracle.com
Wed Feb 10 17:53:29 UTC 2016
It would be nice if we could narrow this bailout only for loops. I mean when Phi's control is loop's head.
If it is an ordinary merge region splitting through it may help to improve performance. What do you think?
Could you run some performance tests to effects. If ordinary region cases are rare then you current fix is good enough.
Thanks,
Vladimir
On 2/10/16 5:11 AM, Roland Westrelin wrote:
> http://cr.openjdk.java.net/~roland/8149543/webrev.00/
>
> Reported by Michael Berg for vectorization optimizations.
> In cases like this:
>
> public static float sumListReduction(float[] a, float[] b, float[] c, float[] d, float total, int process_len)
> {
> for(int i = 0; i < process_len; i++)
> {
> d[i]= (a[i] * b[i]) + (a[i] * c[i]) + (b[i] * c[i]);
> }
>
> total += d[0];
> total += d[process_len-1];
> return total;
> }
>
> Range check CastII nodes are split through the loop induction Phi which causes new Phis to be created that are unrelated to the trip Phi and prevent further optimizations:
>
> Phi 735 718 43 384 [ 784 384 ] bci = 10 debug_orig = dump_spec = #int:>=1:www #tripcount debug_idx = 17200735 line = 32 type = int:
>
> Phi 921 718 43 384 [ 727 ] bci = 16 debug_orig = dump_spec = #int:1..max-1:www debug_idx = 23800921 line = 32 type = int:
>
> I propose we simply don’t split range check CastII nodes through Phis.
>
> Roland.
>
More information about the hotspot-compiler-dev
mailing list