Hi,
I did some tests on the following function
--- CUT HERE --- int fibo(int n) { if (n < 2) return 1; return (fibo(n-2) + fibo(n-1)); } --- CUT HERE ---
and I discovered that it is faster -O2 than -O3. This is with gcc 4.9.2.
Looking at the disassembly I see it is using FP registers to hold integer values. The following is a small extract.
.L3: fmov w0, s8 sub w25, w25, #1 cmn w25, #1 add w0, w0, w27 fmov s8, w0 bne .L19 add w0, w0, 1 b .L2
Recompiling with -mgeneral-regs-only generates a huge improvement.
The following are the times I get on various partner HW. I have normalised the -O2 times to 1 second so that I do not disclose actual partner performance data:
Partner 1: -O2 = 1sec, -O3 = 1.13sec, -O3 -mgeneral-regs-only = 0.72sec Partner 2: -O2 = 1sec, -O3 = 0.68sec, -O3 -mgeneral-regs-only = 0.60sec Partner 3: -O2 = 1sec, -O3 = 0.73sec, -O3 -mgeneral-regs-only = 0.68sec Partner 4: -O2 = 1sec, -O3 = 0.83sec, -O3 -mgeneral-regs-only = 0.84sec
So, in general, -O3 does actually do better than -O2, but in all cases performance is better if I stop it using FP registers for int values.
I have put a tarball of the test program along with 3 binaries and 3 disassemblies here:-
http://people.linaro.org/~edward.nevill/fibo.tar
All the best, Ed.
On Thu, Apr 2, 2015 at 3:19 AM, Edward Nevill edward.nevill@linaro.org wrote:
Looking at the disassembly I see it is using FP registers to hold integer values. The following is a small extract.
-O3 turns on -finline-functions, which causes a lot of code expansion. That, combined with the fact that we end up with a call in the middle of a loop, and most values have lifetimes that cross the call, means that it runs out of registers, and needs to spill. The compiler is then choosing to use FP registers for spills instead of storing/loading to/from the stack. I'm not seeing the same behaviour from the FSF GCC mainline, nor from the linaro-4.9 branch. These are both spilling to stack instead of FP registers.
This appears to be FSF GCC Bug 61915 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61915 which was fixed in November and back ported to our linaro branch last month.
Jim
linaro-toolchain@lists.linaro.org