This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/33761] non-optimal inlining heuristics pessimizes gzip SPEC score at -O3
- 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: 16 Jan 2008 16:46:28 -0000
- Subject: [Bug tree-optimization/33761] non-optimal inlining heuristics pessimizes gzip SPEC score at -O3
- References: <bug-33761-1649@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #11 from hubicka at gcc dot gnu dot org 2008-01-16 16:46 -------
Last time I looked into it, it was code
alignment affected by inlining in the string matching loop (longest_match).
This code is very atypical, since the internal loop comparing strings is hand
unrolled but it almost never rolls, since the compressed strings tends to be
all different. GCC mispredicts this
moving some stuff out of the loop and bb-reorder aligns the code in a
way that the default path not doing
the loop is jumping pretty far
hurting decode bandwidth of K8 especially because the jumps are hard to
predict.
I don't see any direct things in the code heuristics can use to realize
that the loop is not rooling, except for
special casing the particular
benchmark.
FDO scores of gzip are not doing that bad, but there is still gap
relative to ICC (even archaic version of it
running 32bit compared to 64bit GCC).
http://www.suse.de/~gcctest/SPEC-britten/CINT/sandbox-britten-FDO/index.html
It would be nice to convince gzip/zlibc/bzip2 people to use profiling by
default in the build process - those
packages are ideal targets.
But since core is not that much sensitive to code alignment and nuber of
jumps as K8, perhaps there are extra
problems demonstrated by this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33761