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.
