* [Bug target/93802] gcc generates a rlwinm/or pair instead of a single rlwimi (powerpc)
[not found] <bug-93802-4@http.gcc.gnu.org/bugzilla/>
@ 2020-04-30 21:36 ` segher at gcc dot gnu.org
2024-03-06 2:53 ` guihaoc at gcc dot gnu.org
1 sibling, 0 replies; 2+ messages in thread
From: segher at gcc dot gnu.org @ 2020-04-30 21:36 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 2+ messages in thread