[Bug tree-optimization/92282] New: gimple for (a + ~b) is harder to optimize in RTL when types are unsigned

[rearnsha at gcc dot gnu.org]

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

            Bug ID: 92282
           Summary: gimple for (a + ~b) is harder to optimize in RTL when
                    types are unsigned
           Product: gcc
           Version: 10.0
            Status: UNCONFIRMED
          Keywords: missed-optimization
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: rearnsha at gcc dot gnu.org
  Target Milestone: ---

Given:

t f1(t a, t b) { return a + ~b; }

if t is of type int64_t, then the gimple produced is


  _1 = ~b_2(D);
  _4 = _1 + a_3(D);

Which on Arm can then easily optimize into a 3 instruction sequence

MVN  R2, R2
ADDS R0, R0, R2
SBC  R1, R1, R3

(because on Arm, SBC = Rn - Rm - ~C == Rn + ~Rm + C)

But if the type is changed to uint64_t, then the gimple is transformed into

  _1 = a_2(D) - b_3(D);
  _4 = _1 + 18446744073709551615;

Which is almost impossible for the back-end to optimize back into the optimal
sequence.  The result is that we end up with two carry-propagating subtract
operations instead of one and less parallelism in the overall sequence as the
bit-wise invert can operate in parallel on any super-scalar architecture.

Note that the same problem likely exists on 64-bit architectures if t is
uint128_t.