public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug target/93571] PPC: fmr gets used instead of faster xxlor
[not found] <bug-93571-4@http.gcc.gnu.org/bugzilla/>
@ 2020-06-10 21:50 ` segher at gcc dot gnu.org
2021-06-16 6:39 ` luoxhu at gcc dot gnu.org
2021-06-16 6:54 ` luoxhu at gcc dot gnu.org
2 siblings, 0 replies; 3+ messages in thread
From: segher at gcc dot gnu.org @ 2020-06-10 21:50 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93571
Segher Boessenkool <segher at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2020-06-10
Target|powerpc-*-*-* |powerpc*-*-*
CC| |segher at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Segher Boessenkool <segher at gcc dot gnu.org> ---
Interesting! I tried it out, and indeed xxlor is 2 cycles while fmr is 6,
on p8 and p7, it's not just a documentation artefact. Apparently fmr goes
through the FP pipeline (while it doesn't have to, of course -- well it
may be easier to implement "fmr." this way, even that isn't needed).
It does not normally matter very much, but still. Confirmed.
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug target/93571] PPC: fmr gets used instead of faster xxlor
[not found] <bug-93571-4@http.gcc.gnu.org/bugzilla/>
2020-06-10 21:50 ` [Bug target/93571] PPC: fmr gets used instead of faster xxlor segher at gcc dot gnu.org
@ 2021-06-16 6:39 ` luoxhu at gcc dot gnu.org
2021-06-16 6:54 ` luoxhu at gcc dot gnu.org
2 siblings, 0 replies; 3+ messages in thread
From: luoxhu at gcc dot gnu.org @ 2021-06-16 6:39 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93571
luoxhu at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |luoxhu at gcc dot gnu.org
--- Comment #2 from luoxhu at gcc dot gnu.org ---
It is generated by "*mov<mode>_hardfloat64" (i.e. {*movdf_hardfloat64}), switch
the constraint of fmr and xxlor could generate expected code, is that correct?
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug target/93571] PPC: fmr gets used instead of faster xxlor
[not found] <bug-93571-4@http.gcc.gnu.org/bugzilla/>
2020-06-10 21:50 ` [Bug target/93571] PPC: fmr gets used instead of faster xxlor segher at gcc dot gnu.org
2021-06-16 6:39 ` luoxhu at gcc dot gnu.org
@ 2021-06-16 6:54 ` luoxhu at gcc dot gnu.org
2 siblings, 0 replies; 3+ messages in thread
From: luoxhu at gcc dot gnu.org @ 2021-06-16 6:54 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93571
--- Comment #3 from luoxhu at gcc dot gnu.org ---
BTW, I didn't see performance difference between fmr and xxlor within a small
benchmark.
Max Ops Per Cycle Latency (Min) Latency (Max)
fmr - - ALU FPR 4 2
2 1 R - - - -
Floating Move Register
xxlor - - ALU VSR 2 2
2 1 V - 1 S - -
VSX Vector Logical OR
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2021-06-16 6:54 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <bug-93571-4@http.gcc.gnu.org/bugzilla/>
2020-06-10 21:50 ` [Bug target/93571] PPC: fmr gets used instead of faster xxlor segher at gcc dot gnu.org
2021-06-16 6:39 ` luoxhu at gcc dot gnu.org
2021-06-16 6:54 ` luoxhu at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).