Marc:
I've been thinking about how to get the C code generated by gsc to conform to the ISO C standard. Beyond being just a "good thing", this would allow us to get rid of the -fwrapv and -fno-strict- aliasing flags in gcc, which would also enable some further compiler optimizations. (Well, getting rid of -fwrapv enables some optimizations and disables others.)
I think the only places in the gambit back-end where we assume that signed arithmetic wraps on overflow are in the macros FIXADDP, FIXMULP, and FIXSUBP in gambit.h. I'm no expert on signed vs. unsigned arithmetic in C, but I think that simply casting the arguments of the possibly overflowing operations to unsigned, and then casting the result back to signed, will, in the end, give us the same result but will be standard-conforming.
So I offer this (lightly tested, but it did pass "make check") patch for gambit.h that does precisely this. This should allow us to omit the -fwrapv flag for gcc. I don't have any performance figures for gsc compiled without -fwrapv, but the binary is a bit smaller:
[brad:~/programs/gambc-4.0b22] lucier% ll gsc/gsc gsc-comp -rwxr-xr-x 1 lucier lucier 5544476 Apr 6 19:11 gsc-comp* -rwxr-xr-x 1 lucier lucier 5540296 Apr 15 17:58 gsc/gsc*
The patch also has an extra guard to limit the use of __builtin_expect to versions of gcc >= 3.0.
Brad
Afficher les réponses par date
Marc:
On Apr 15, 2007, at 6:39 PM, Bradley Lucier wrote:
This should allow us to omit the -fwrapv flag for gcc. I don't have any performance figures for gsc compiled without -fwrapv,
OK, I have these now, and it seems to be a wash using -fwrapv, but it is an advantage (about 4%) to use gcc-4.1.2 on a Powerbook instead of Apple's current release of 4.0.1.
I timed my soon-to-be-released replacement for fft bignum multiplication on a 1.67GHz G4 Powerbook. Bottom line for (fft-mul a b) with (not (eq? a b)) and both = to (expt 3 1000000):
With -fwrapv: 702 ms With fixed gambit.h and no -fwrapv: 708 ms With fixed gambit.h and no -fwrapv and -fstrict-aliasing: 658 ms
The latter is valid because there are no aliasing violations in fftmul-fast.scm. The code in _num.scm takes 733 ms, so the new code is clearer and provably correct, but it's faster.
The number of cycles that the main loop of the direct (forward) fft is scheduled by gcc-4.1.2:
With or without -fwrapv: 111 With fixed gambit.h and no -fwrapv and -fstrict-aliasing: 68(!)
This loop has 40 floating-point instructions. We're talking a speedup of
(/ 733 658.)
1.1139817629179332
just by tweaking the macros in gambit.h.
Brad
-
Bradley Lucier