This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/23322] [4.1/4.2/4.3 regression] performance regression
- From: "hubicka at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 8 Feb 2008 14:54:44 -0000
- Subject: [Bug target/23322] [4.1/4.2/4.3 regression] performance regression
- References: <bug-23322-10914@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #29 from hubicka at gcc dot gnu dot org 2008-02-08 14:54 -------
Hi,
tonight results from Haydn shows 32bit scores with the loop-invariant hack
disabled.
http://www.suse.de/~gcctest/SPEC/CFP/sb-haydn-head-64-32o-32bit/index.html
There are no off noise speedups though I must admit that the 32bit results from
Haydn are truly noisy. I also did runs by hand and those also don't seem much
difference, but the noise factor is always dificult to estimate in little stuff
like this.
I will give it a run on britten too to double check, it was running different
patch tonight.
However I wonder if you do have testcases where the hack helps. In general we
can
1) ignore the problem
2) disable the hack for loop-invariant only (not for GCSE). Loop-invariant is
more sure about benefits and already has some heuristics to limit the pressure.
I do agree that in general having too many stuff in x87 registers kills the
perofmrance on very random basis.
3) come up with more cureful heuristics for loop-invariant. Perhaps based on
number of loop carried variables or numebr of FP registers live across loopback
edge.
For 3 we would need test also benchmarks that originally exposed the problem.
I see it was tested on povray, it would be nice the the test was repeated (and
I can probably do that if no one volunteers ;)
Honza
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23322