https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92549
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |10.0
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92549
--- Comment #7 from Jakub Jelinek ---
Author: jakub
Date: Tue Nov 19 09:31:59 2019
New Revision: 278439
URL: https://gcc.gnu.org/viewcvs?rev=278439&root=gcc&view=rev
Log:
PR target/92549
* config/i386/i386.md (peephole2 for *swap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92549
--- Comment #6 from Segher Boessenkool ---
(In reply to Richard Biener from comment #2)
> But it looks like x86 has exactly patterns like this - but in this case
> I guess combine won't ever try this because hardregs are invovled
> (not sure if i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92549
--- Comment #5 from Jakub Jelinek ---
Further info on the topic:
https://stackoverflow.com/questions/45766444/why-is-xchg-reg-reg-a-3-micro-op-instruction-on-modern-intel-architectures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92549
--- Comment #4 from Jakub Jelinek ---
E.g. Agner Fog has in the tables for Atom mov r,r 1uops, latency 1, rec.
throughput 1/2, while for xchg r,r 3uops, latency 6, rec. throughput 6.
It doesn't look beneficial speed wise then.
Though, even say on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92549
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92549
Richard Biener changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92549
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Target|
