--- Comment #55 from bonzini at gnu dot org 2009-05-06 09:20 ---
Created an attachment (id=17807)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17807action=view)
svn diff of cse.c to fix the performance regression (updated)
--
bonzini at gnu dot org changed:
What
--- Comment #56 from bonzini at gnu dot org 2009-05-06 09:31 ---
Created an attachment (id=17808)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17808action=view)
usable testcase
Ok, I managed to make a reasonably readable source code (uninclude stdlib
files, remove unused gambit
--- Comment #57 from jakub at gcc dot gnu dot org 2009-05-06 09:49 ---
Why do you need any #include lines at all in the reduced testcase? Compiles
just fine even without them...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
--- Comment #58 from bonzini at gnu dot org 2009-05-06 09:56 ---
Uhm, it's better to run unpatched 4.5 with -O1 -fforward-propagate to get a
fair comparison. Also, I was counting the loop headers, which are not part of
the hot code.
4.2 -O1 4.5 -O1 -ffw-prop
--- Comment #59 from bonzini at gnu dot org 2009-05-06 09:59 ---
Created an attachment (id=17809)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17809action=view)
usable testcase
Without includes as Jakub suggested.
--
bonzini at gnu dot org changed:
What
--- Comment #60 from bonzini at gnu dot org 2009-05-06 10:47 ---
Actually those are created by -fmove-loop-invariants. With -O1
-fforward-propagate -fno-move-loop-invariants I get:
4.5 -O1 -ffw-prop -fno-move-loop-inv
LOOP 1183
INNER LOOP 1.1
--- Comment #53 from lucier at math dot purdue dot edu 2009-05-06 03:43
---
I posted a possible fix to gcc-patches with the subject line
Possible fix for 30% performance regression in PR 33928
Here's the assembly for the main loop after the changes I proposed:
.L4230:
movq
--- Comment #54 from lucier at math dot purdue dot edu 2009-05-06 03:50
---
Created an attachment (id=17805)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17805action=view)
svn diff of cse.c to fix the performance regression
This partially reverts r118475 and adds code to call
--- Comment #52 from lucier at math dot purdue dot edu 2009-04-26 18:27
---
I narrowed down the new performance regression to code added some time around
March 12, 2009, so I changed back the subject line of this PR to reflect the
performance regression caused only by the code added
