This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: maybe_infinite_loop?


On 4/21/07, Mike Stump <mrs@apple.com> wrote:
We still have some lno bits in our tree.  We tried to remove them and
found:

gzip +0.5%
vpr -0.4%
gcc -3.2%
mcf -0.3%
crafty +0.2%
parser +0.2%
perlbmk -2.2%
gap +0.2%
vortex -0.1%
bzip2 +1.9%
twolf -0.7%

on x86 (probably a core2 duo) in our 4.2 tree (with the rest of our
local patches).  -3.2% means a 3.2% better codegen (roughly) with the
lno bits.  I didn't rerun the numbers for mainline to see if they are
still applicable.

Of all the LNO bits, the last major bits seems to be the below bit.
I don't even know if it is responsible for the benefit we see.  I
thought I'd mention it, as a 2-3% win on two of the spec tests seems
worthwhile.

I'd be interested in finding someone that might be interested in
tracking down where the benefit comes from in the patch and pushing
into mainline what goodness there is to be had from the patch.  Any
takers?  If I can find someone, I'd be happy to send out the version
of the patch for mainline.  [ hum just 567 lines]

I hope you changed the way it works Honestly, this patch was the wrong way to mark such loops (IE using a fake builtin function), and died on the LNO branch like it should have. If it really produces benefits, then rewrite it to something sane.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]