[Bug tree-optimization/113268] New: (i + (i + 1) * CST) AND (i + i * CST + 1 * CST) not folded the same way

[Bug tree-optimization/113268] New: (i + (i + 1) * CST) AND (i + i * CST + 1 * CST) not folded the same way

[denis.campredon at gmail dot com]

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

            Bug ID: 113268
           Summary: (i + (i + 1) * CST) AND (i + i * CST + 1 * CST) not
                    folded the same way
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: denis.campredon at gmail dot com
  Target Milestone: ---

The two following functions should produce the same assembly with optimizations
enabled.

This lead, for exemple, to missed optimization with -Oz

---------------
#define CST 36

int foo(int i)
{
    return i + (i + 1) * CST;
}

int bar(int i)
{
    return i + i * CST + 1 * CST;
}
---------------

foo:
        lea     eax, [rdi+1]
        imul    eax, eax, 36
        add     eax, edi
        ret
bar:
        imul    eax, edi, 37
        add     eax, 36
        ret

[Bug tree-optimization/113268] (i + (i + 1) * CST) AND (i + i * CST + 1 * CST) not folded the same way

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
           Keywords|                            |missed-optimization
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2024-01-09

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
(i + 1) * CST and i * CST + 1 * CST can have different overflow behavior,
so (i + 1) * CST cannot be turned into i * CST + CST unconditionally.
The reverse transform would be valid through I think.

RTL or GIMPLE with -fwrapv should be able to handle both the same.  There's
still the old idea of making late GIMPLE effectively -fwrapv, the same as RTL
behaves.