The C memory aliasing model allows certain kinds of optimizations.

For example, consider the following code that's generated at the end the main loop of the FFT in _num.scm (after pulling it out of ##bignum.*):

___F64VECTORSET(___STK(-5),___R3,___F64V53) ___F64VECTORSET(___STK(-5),___R4,___F64V52) ___F64VECTORSET(___STK(-5),___STK(1),___F64V51) ___F64VECTORSET(___STK(-5),___STK(2),___F64V50) ___F64VECTORSET(___STK(-5),___STK(3),___F64V49) ___F64VECTORSET(___STK(-5),___STK(4),___F64V48) ___F64VECTORSET(___STK(-5),___STK(5),___F64V47) ___F64VECTORSET(___STK(-5),___STK(6),___F64V46) ___SET_R3(___FIXADD(___R3,___FIX(2L))) ___POLL(9) ___DEF_SLBL(9,___L9_direct_2d_fft_2d_recursive_2d_4) ___GOTO(___L22_direct_2d_fft_2d_recursive_2d_4)

Here we're alternating loading elements off the stack and storing floating-point values in a vector.

Under C's memory aliasing model (i.e., with -fstrict-aliasing, the gcc default), STK(-5) can be loaded into a register and reused after each floating-point store, because gcc can assume that the floating-point store does not change the value of STK(-5), since WORDs and doubles are different types.

When we call gcc with -fno-strict-aliasing, then the compiler has to assume that the floating-point store may affect the value of STK(-5), so it has to reload STK(-5) before each floating-point store.

This has the following effect on the time to compute 10,000 forward and 10,000 backward complex FFTs of 1,024 elements.

With -fno-strict-aliasing (used now by Gambit for reasons I'll explain below):

(time (do ((i 0 (fx+ i 1))) ((fx= i 10000)) (direct-fft-recursive-4 a table) (inverse-fft-recursive-4 a table) (do ((i 0 (fx+ i 1))) ((fx= i (fx* two^n 2))) (f64vector-set! a i (fl/ (f64vector-ref a i) inexact-two^n))))) 705 ms real time 704 ms cpu time (704 user, 0 system) 6 collections accounting for 2 ms real time (0 user, 0 system) 1600000 bytes allocated 22 minor faults no major faults

With -fstrict-aliasing:

(time (do ((i 0 (fx+ i 1))) ((fx= i 10000)) (direct-fft-recursive-4 a table) (inverse-fft-recursive-4 a table) (do ((i 0 (fx+ i 1))) ((fx= i (fx* two^n 2))) (f64vector-set! a i (fl/ (f64vector-ref a i) inexact-two^n))))) 590 ms real time 592 ms cpu time (588 user, 4 system) 6 collections accounting for 2 ms real time (4 user, 0 system) 1600000 bytes allocated 22 minor faults no major faults

That's a 19% performance improvement. (And the performance isn't bad, 1.74 GFLOPS on my 2.33GHz Core 2 quad 6600. Later I'll try to get gcc to vectorize the main loop.)

As I understand it, the C memory aliasing model is that once you store something of a certain type into a memory location, then you agree that everything you read from that memory location and everything else you write to that memory location will be of the same type.

So why do we need -fno-strict-aliasing? I know of two reasons: (1) in gambit.h we read and write bignums as adigits, mdigits, or fdigits, and these are chunks of the bignums of different sizes (generally 64/32/8 bits on 64-bit machines, and 64/16/8 bits on 32-bit machines) and (2) I believe we sometimes access double-precision floating-point numbers as integers. Marc, maybe you know of other instances in the code.

Both of these things can be fixed by accessing the internals of a bignum through a pointer type to a union of vectors of integers of the appropriate bit sizes, and doing the same for double-precision floats. (I had a much more difficult plan in mind before, of coming up with a union type of all possible Scheme objects, but that isn't necessary, I see now.)

I've been trying to figure out how to make the changes to gambit.h to do this in a clean way but without luck. Marc, you're the über programmer, do you have time to look at this?

Brad