[Bug target/102032] New: missed optimization on 2 equivalent expressions when -fwrapv is not used

[Bug target/102032] New: missed optimization on 2 equivalent expressions when -fwrapv is not used

[vincent-gcc at vinc17 dot net]

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

            Bug ID: 102032
           Summary: missed optimization on 2 equivalent expressions when
                    -fwrapv is not used
           Product: gcc
           Version: 11.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: vincent-gcc at vinc17 dot net
  Target Milestone: ---

Consider the following code from bug 30484:

int f (int a, int b, int c)
{
  if (b < 0)
    return a + b + c;
  else
    return a + c + b;
}

On x86_64 with -O3, GCC 11.2.0 gives

        leal    (%rdi,%rdx), %eax
        addl    %esi, %edi
        addl    %edx, %edi
        addl    %esi, %eax
        testl   %esi, %esi
        cmovs   %edi, %eax

But x86_64 processors (and most processors, AFAIK) do not care about overflows,
so that a + b + c and a + c + b are actually equivalent for the processor and
one should get only 2 instructions, corresponding to the 2 additions.
Surprisingly, -fwrapv has the effect to allow this optimization, with the
following generated code:

        addl    %edx, %edi
        leal    (%rdi,%rsi), %eax

[Bug tree-optimization/102032] missed optimization on 2 equivalent expressions when -fwrapv is not used

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|target                      |tree-optimization
   Last reconfirmed|                            |2021-08-24
           Severity|normal                      |enhancement
     Ever confirmed|0                           |1
           Keywords|                            |missed-optimization
             Status|UNCONFIRMED                 |NEW

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed, one way of fixing this is to have a "lower" gimple where signed
integer overflow does not matter and then we can reassociate all we want. There
is a simple reassociatation on the RTL level but it does not catch everything.

[Bug tree-optimization/102032] missed optimization on 2 equivalent expressions when -fwrapv is not used

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Note for the RTL level PLUS for SImode has no knowledge of signed vs unsigned,
it is just an add and will always wrap.

[Bug tree-optimization/102032] missed optimization on 2 equivalent expressions when -fwrapv is not used

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #1)
> Confirmed, one way of fixing this is to have a "lower" gimple where signed
> integer overflow does not matter and then we can reassociate all we want.
> There is a simple reassociatation on the RTL level but it does not catch
> everything.

Yes, that would fix it.  There's some PR with a proof-of-concept patch.
One of the issues with -fno-wrapv is that we cannot re-associate signed
integer operations and thus 'a+b+c' and 'a+c+b' are not considered equal
by value-numbering.  With -frapv they are re-associated and are
value-numbered the same, simplifying the code.

Re-association could re-associate the signed integer ops by using
unsigned computations but that's not implemented.

[Bug tree-optimization/102032] missed optimization on 2 equivalent expressions when -fwrapv is not used

[vincent-gcc at vinc17 dot net]

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

--- Comment #4 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
Note that as said in PR111560 comment 6, re-association may break CSE, e.g. if
there are also a + b + d and a + c + e with my example. So, re-association for
global optimal CSE, in addition to being difficult, will not allow the
optimization in all cases of equivalent expressions.