[Bug c/82940] Suboptimal code for (a & 0x7f) | (b & 0x80) on powerpc

["segher at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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

--- Comment #3 from Segher Boessenkool <segher at gcc dot gnu.org> ---
In combine, we start with


insn_cost 4 for    10: r137:SI=r136:QI#0&0x7f
      REG_DEAD r136:QI
insn_cost 4 for    13: r140:SI=r132:SI&0xffffffffffffff80
      REG_DEAD r132:SI
insn_cost 4 for    16: r143:SI=r137:SI|r140:SI
      REG_DEAD r140:SI
      REG_DEAD r137:SI
insn_cost 4 for    17: r144:SI=zero_extend(r143:SI#3)
      REG_DEAD r143:SI


It then tries:


Trying 13, 10 -> 16:
   13: r140:SI=r132:SI&0xffffffffffffff80
      REG_DEAD r132:SI
   10: r137:SI=r136:QI#0&0x7f
      REG_DEAD r136:QI
   16: r143:SI=r137:SI|r140:SI
      REG_DEAD r140:SI
      REG_DEAD r137:SI
Failed to match this instruction:
(set (reg:SI 143)
    (ior:SI (and:SI (reg/v:SI 132 [ v+-3 ])
            (const_int 128 [0x80]))
        (and:SI (subreg:SI (reg:QI 136 [ *_2 ]) 0)
            (const_int 127 [0x7f]))))


which fails because that isn't an existing instruction (the -0x80 was
optimised to 0x80).

Then 16->17 is done (throwing away the useless extend), and of course
10,13->17 won't work after that.


So it's a case of the general problem that combine using known values
of registers often hurts instead of helps.