https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69274
Bug 69274 depends on bug 69689, which changed state.
Bug 69689 Summary: gcc.target/i386/addr-sel-1.c FAILs with PR69274 fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69689
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69274
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69274
--- Comment #14 from Richard Biener ---
Author: rguenth
Date: Mon Feb 8 09:09:22 2016
New Revision: 233209
URL: https://gcc.gnu.org/viewcvs?rev=233209&root=gcc&view=rev
Log:
2016-02-08 Richard Biener
PR rtl-optimization/69274
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69274
--- Comment #13 from Richard Biener ---
It would be interesting to see whether FDO also shows the regression (I only
have a non-march=native FDO tester and the non-march=native tester doesn't show
the regression already). Because it might be tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69274
--- Comment #12 from Richard Biener ---
Key assembly difference seems to be extra reg-reg copies around a loop. But
maybe
perf lies to me (the description cites fsettle as the real offender but perf
points me to inl1130). As I can reproduce the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69274
--- Comment #11 from Richard Biener ---
Alternate fix not causing PR69689 (but also not getting the extra speedup
observed with the original fix):
Index: gcc/ira.c
===
--- gcc/ira.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69274
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69274
--- Comment #9 from Richard Biener ---
Slowdown also reproduces with -fno-schedule-insns2 which makes reading the
assembly difference easier.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69274
--- Comment #7 from Richard Biener ---
So the main question remains - why's the patch not a no-op on x86_64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69274
--- Comment #8 from Richard Biener ---
Ok, it's if in the old code operand zero didn't match we didn't process further
operands which may have had the '%'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69274
--- Comment #6 from Richard Biener ---
Created attachment 37580
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37580&action=edit
preprocessed source
source for the function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69274
--- Comment #5 from Richard Biener ---
Samples: 2M of event 'cycles', Event count (approx.): 1928893785632
36.40% gromacs_base.am gromacs_base.amd64-m64-gcc42-nn [.] inl1130_
28.60% gromacs_peak.am gromacs_peak.amd64-m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69274
Richard Biener changed:
What|Removed |Added
Keywords||ra
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69274
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69274
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69274
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Status|
16 matches
Mail list logo
