[Bug target/93802] gcc generates a rlwinm/or pair instead of a single rlwimi (powerpc)

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

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

Segher Boessenkool <segher at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |segher at gcc dot gnu.org
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2020-04-30

--- Comment #1 from Segher Boessenkool <segher at gcc dot gnu.org> ---
Confirmed.  Needs -m32.

There are complications from parameter passing.  Making x a global doesn't
improve things: the zero-extend becomes part of the memory access, which
prevents us from optimising it well later.

Adding something like
  x *= 42;
as extra first line doesn't work, either:
Failed to match this instruction:
(set (reg:SI 124)
    (ior:SI (and:SI (reg:SI 123)
            (const_int 65534 [0xfffe]))
        (ashift:SI (reg:SI 123)
            (const_int 16 [0x10]))))

(Note combine has figured out the low bit is always zero,  How helpful ;-) )

But with
  x *= 421;
we get
f:
        mulli 3,3,421    # 6    [c=8 l=4]  mulsi3/1
        rlwimi 3,3,16,0,31-16    # 14   [c=4 l=4]  *rotlsi3_insert_3
        blr              # 22   [c=4 l=4]  simple_return

which is exactly what we wanted.


Both the original case and the "even" case should work better if we had
better known bits tracking (the "even" one could maybe be made to work
already, even, in target code).