On Tue, May 18, 2021 at 1:26 PM Richard Earnshaw via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
>
>
>
> 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.
Note some less special crafting might be needed when using
the GIMPLE FE and you start right with RTL expansion
via __GIMPLE (ssa,startwith("expand"))
-fdump-tree-optimized-gimple should provide rough GIMPLE FE
input.
Richard.
> R.
>
> >
> > brgds, H-P
> >
