RFR(XS): 8211451: ~2.5% regression on compression benchmark starting with 12-b11

[Vladimir Kozlov]

I am really hesitating to relax counted loop conditions but let summarize what we are discussing.

The only troubling case when 'ne' is not converted to < or > and init >= limit (or we can't prove during compilation 
that init < limit).

The checking that first increment does not overflow (init_t->_hi > max_jint - stride_con) will not help with 'ne' 
condition because even after first increment 'ne' will be true for init > limit case.

You are saying that don't do that check since this condition will not help to avoid overflow anyway. Right?

And to make this regression go away we need to convert test's loop into counted loop and unroll it even with 'ne' 
condition. Right?

Can we strengthen code by adding runtime check (predicate) for 'ne' case that init < limit? We do this for limit today.

Thanks,
Vladimir

On 10/18/18 1:54 AM, Roland Westrelin wrote:
> 
>> Right, it is not infinite but the issue here is not how many iterations we run but validity of checks in generated code
>> we will add during counted loop optimizations (iteration splitting, unrolling, ...). Do we execute loop optimization if
>> condition is 'ne'?
> 
> We do. In the method where the regression shows up, the loop is unrolled
> for instance.
> 
> Roland.
>