[Bug tree-optimization/109862] New: IV-OPTs could use int but still uses smaller sized for IV

[Bug tree-optimization/109862] New: IV-OPTs could use int but still uses smaller sized for IV

[pinskia at gcc dot gnu.org]

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

            Bug ID: 109862
           Summary: IV-OPTs could use int but still uses smaller sized for
                    IV
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Keywords: missed-optimization
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
            Target: aarch64, riscv32, riscv64

Take:
```
int f(char a)
{
        unsigned char t;
        unsigned short t1 = a;
        for(t = 0; t < 8; t ++)
        {
                t1 >>=1;
                t1 += a;
        }
        return t1;
}
int f1(char a)
{
        unsigned int t;
        unsigned short t1 = a;
        for(t = 0; t < 8; t ++)
        {
                t1 >>=1;
                t1 += a;
        }
        return t1;
}

```
f1 produces better code as there is no extra zero-extend (anding) inside the
loop for the IV of t.

Note this shows up in coremarks in the crc functions (if not unrolling).

[Bug tree-optimization/109862] IV-OPTs could use int but still uses smaller sized for IV

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement

[Bug tree-optimization/109862] IV-OPTs could use int but still uses smaller sized for IV

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
I think IVOPTs never considers candidates of different size.  One could use
niter info to bound the value range (or use ranger) and add a candidate based
on that.  But you have to be careful with targets that cannot do sub-word
arithmetic efficiently.