This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/81554] [8 Regression] 25% performance regression in Himeno benchmark
- From: "rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 26 Jul 2017 08:52:04 +0000
- Subject: [Bug tree-optimization/81554] [8 Regression] 25% performance regression in Himeno benchmark
- Auto-submitted: auto-generated
- References: <bug-81554-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81554
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2017-07-26
CC| |hubicka at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Bah.
I wonder if we should drop to -fwrapv semantics (thus RTL semantics) at some
point after GIMPLE loop optimizations, preferably before reassoc after loop.
It shouldn't be too difficult to implement that (well, just a "bit" ugly)
to try benchmarking it. To do it "cleanly" we'd add/change the optimization
node associated with cfun. In a new pass_late_gimple_begin do
pop_cfun ();
<adjust opt node>
push_cfun ();
unless fwrapv/ftrapv is already set, of course.
Going to try sth like that.