[Bug rtl-optimization/55278] [4.8/4.9 Regression] Botan performance regressions apparently due to LRA

["vmakarov at redhat dot com" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55278

--- Comment #11 from Vladimir Makarov <vmakarov at redhat dot com> ---
I don't see a code degradation because of LRA.  Here what I got using gcc4.8
branch compiler with options -O3  -finline-functions  -D_REENTRANT
-Wno-long-long -W -Wall -fPIC -fvisibility=hidden on Xeon X5660 and i7-2600
(sandy bridge):

64-bit:

real=16.78 user=16.57 system=0.00
real=16.39 user=16.20 system=0.00
real=16.81 user=16.57 system=0.00
real=16.35 user=16.20 system=0.00
real=16.82 user=16.56 system=0.00
real=16.40 user=16.20 system=0.00

real=7.37 user=7.34 system=0.00
real=7.05 user=7.02 system=0.00
real=7.34 user=7.31 system=0.00
real=7.05 user=7.02 system=0.00
real=7.37 user=7.31 system=0.00
real=7.05 user=7.02 system=0.00


32-bit:

real=15.46 user=15.22 system=0.00 share=98%%
real=14.53 user=14.21 system=0.00 share=97%%
real=15.77 user=15.41 system=0.00 share=97%%
real=14.49 user=14.23 system=0.00 share=98%%
real=15.57 user=15.22 system=0.00 share=97%%
real=14.51 user=14.23 system=0.00 share=98%%

real=10.17 user=10.13 system=0.00
real=7.76 user=7.73 system=0.00
real=10.17 user=10.13 system=0.00
real=7.76 user=7.73 system=0.00
real=10.17 user=10.13 system=0.00
real=7.76 user=7.73 system=0.00

The first run is for gcc-4.8 with reload the second run with LRA. It is
repeated 3 times. LRA generates a better code for this test on both CPU in 32
and 64-bit mode.

Although LLVM new reg allocator might generate better code than LRA or reload
or may be there is another reason for this.  To be honest I don't know.

I looked at http://gcc.opensuse.org/c++bench/botan/botan-summary.txt-1-0.html
and I see that KASUMI was improved about October.  I worked on botan after LRA
merge and as I remember some benchmarked became worse, some were improved but
in overall (run time for all algorithms) was about the same.

I don't have 3.3 LLVM but I using 3.2 I am getting on i7-2600
7.378s(64-bit) and 7.234s (32-bit) using the option above vs 7.02s and 7.73s
for gcc4.8 (LRA).  So I can not confirm the big difference on KASUMI reported
on http://www.phoronix.com/scan.php?page=article&item=llvm_32_egging&num=2.

It seems to me phoronix is very LLVM biased and that is not good for its
credibility.