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

[Vladimir Kozlov]

On 10/17/18 12:33 AM, Roland Westrelin wrote:
> 
>>> The test for equality is turned into an inequality check only if init <
>>> limit is known and stride == 1 (or a similar condition for stride =
>>> -1). In that case i += stride can't overflow.
>>
>> Where this is done?
> 
>    // Now we need to canonicalize loop condition.
>    if (bt == BoolTest::ne) {
>      assert(stride_con == 1 || stride_con == -1, "simple increment only");
>      // 'ne' can be replaced with 'lt' only when init < limit.
>      if (stride_con > 0 && init_t->_hi < limit_t->_lo)
>        bt = BoolTest::lt;
>      // 'ne' can be replaced with 'gt' only when init > limit.
>      if (stride_con < 0 && init_t->_lo > limit_t->_hi)
>        bt = BoolTest::gt;
>    }

This check does not apply to case which I am concern - overflow (init_t->_hi >= limit_t->_hi). If 'ne' is converted to 
'lt' or 'gt' I don't have concern with such transformation. But what if 'ne' is kept since condition did not pass?

> 
>>> If the equality check is kept, i+stride can overflow only if init >
>>> limit and that would be an infinite loop anyway.
>>
>> This argument does not hold. You are converting loop into counted loop for which loop optimizations
>> assume that it is not infinite.
> 
> So it's not an infinite loop. It's a very long running loop. What I'm
> saying is if there's an overflow of i+stride then init > limit and
> converting it to a counted loop doesn't make it run for a different
> number of iterations.

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'?

Thanks,
Vladimir

> 
> Roland.
>