[committed] arm: correctly handle inequality comparisons against max constants [PR100563]

[Richard Earnshaw]

On 17/05/2021 21:52, Hans-Peter Nilsson wrote:
> On Thu, 13 May 2021, Richard Earnshaw via Gcc-patches wrote:
>>
>> Normally we expect the gimple optimizers to fold away comparisons that
>> are always true, but at some lower optimization levels this is not
>> always the case, so the back-end has to be able to generate correct
>> code in these cases.
>>
>> In this example, we have a comparison of the form
>>
>>    (unsigned long long) op <= ~0ULL
>>
>> which, of course is always true.
>>
>> Normally, in the arm back-end we handle these expansions where the
>> immediate cannot be handled directly by adding 1 to the constant and
>> then adjusting the comparison operator:
>>
>>    (unsigned long long) op < CONST + 1
>>
>> but we cannot do that when the constant is already the largest value.
> 
> Sounds like a target-independent bug in the making, lurking and
> waiting for a target to do the above adjustment but missing the
> bounds-check.
> 

The normal canonicalize_comparison operation tries to simplify 
expressions by reducing the value towards zero and making the 
appropriate adjustment to the comparison.  Arm is a bit different due to 
the way constants are encoded and also because of the limitations on how 
we expand DImode in the backend.  So I don't think this is quite as 
general as you suggest.

>>   gcc/testsuite/gcc.dg/pr100563.c |  9 +++++++++
>>   2 files changed, 34 insertions(+), 4 deletions(-)
>>   create mode 100644 gcc/testsuite/gcc.dg/pr100563.c
> 
> I'll therefore humbly suggest the test-case adjusted to be a
> run-time check (and if not done by others, projecting to do that
> myself...some time late next summer9.

That being said, I won't object if you want to /add/ an additional test 
to try to catch this; but this test had to be quite carefully crafted to 
hit the specific bug in the arm expanders, so I'd prefer that it wasn't 
modified directly.

R.

> 
> brgds, H-P
>