[Bug tree-optimization/108748] New: Enhancement: track ranges of poly_int indeterminates

[Bug tree-optimization/108748] New: Enhancement: track ranges of poly_int indeterminates

[rsandifo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108748

            Bug ID: 108748
           Summary: Enhancement: track ranges of poly_int indeterminates
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: rsandifo at gcc dot gnu.org
  Target Milestone: ---

I've no idea how this would work in practice, just recording it as an
idea/TODO, but: it would be nice if code guarded by a range check on a poly_int
could be optimised for the implied range of the indeterminates.  Maybe ranger
could be taught to do this.

One simple example is:

#include <arm_sve.h>

uint64_t foo(uint64_t x)
{
  if (svcntb() == 2)
    x += svcntb() * 100;
  return x;
}

which generates:

        cntb    x1
        cmp     x1, 2
        cntd    x1, all, mul #3
        lsl     x1, x1, 8
        add     x1, x0, x1
        incb    x1, all, mul #4
        csel    x0, x1, x0, eq
        ret

whereas the equivalent:

#include <arm_sve.h>

uint64_t foo(uint64_t x)
{
  if (svcntb() == 2)
    x += 200;
  return x;
}

generates:

        cntb    x1
        cmp     x1, 2
        add     x1, x0, 200
        csel    x0, x1, x0, eq
        ret

A more realistic use case would be to guard a block of code with a particular
VL in the hope that the code would be optimised for that VL.

[Bug tree-optimization/108748] Enhancement: track ranges of poly_int indeterminates

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108748

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
                 CC|                            |amacleod at redhat dot com
   Last reconfirmed|                            |2023-02-10

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
The GIMPLE we see sems to be

uint64_t foo (uint64_t x)
{
  <bb 2> :
  if (POLY_INT_CST [16, 16] == 2)
    goto <bb 3>; [INV]
  else
    goto <bb 4>; [INV]

  <bb 3> :
  x_6 = x_5(D) + POLY_INT_CST [1600, 1600];

  <bb 4> :
  # x_4 = PHI <x_5(D)(2), x_6(3)>
  return x_4;

so any such optimization would derive the TU wide constant(?) N that is
applied to all POLY_INT_CSTs?  Is there a set_svcntb (..) intrinsic that
would clobber such knowledge?

That said, we'd track a "virtual" variables range here.  For the above
I wonder why we cannot constant fold it - [16, 16] can never be 2, no?

[Bug tree-optimization/108748] Enhancement: track ranges of poly_int indeterminates

[rsandifo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108748

--- Comment #2 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #1)
> That said, we'd track a "virtual" variables range here.  For the above
> I wonder why we cannot constant fold it - [16, 16] can never be 2, no?
Hah!  Yes.  Looks like I inadvertently filed a second bug.

The test was supposed to compare with 16 or use svcntd().