This is the mail archive of the
mailing list for the GCC project.
Re: [RFC PATCH, x86_64] Use -mno-sse[,2] to fall back to x87 FP argument passing convention
On Tue, 10 Oct 2006, Uros Bizjak wrote:
> > Has anyone recently revisited the -mfpmath=* issue with SPEC or
> > acovea? I'm sure Uros can detail the current situation with POV-ray.
> I have results for povray-3.6.1 on "Intel(R) Xeon(TM) CPU 3.60GHz",
> 32bit code:
Your patch was about 64bit code, so how povray behaves on 32bit is, though
interesting, not relevant. Sorry to be shortspoken, as you can see I
really don't like the idea of x87 with -m64 :)
> I would like to expand the rationale for my proposed change a bit.
> Having -mno-sse that would fall-back to 387, we would have following
> choices for x86_64:
All your following argumentation requires that we agree that -mno-sse
(while still wanting fp) with -m64 is a good idea at all. My position is,
that it isn't.
That XFmode still maps to x87 registers was an unfortunate glitch while
implementing x86-64 support :-/
> OTOH, I see no problems having two competing FP subsystems. I'm sure
> that for certain problems, one is better than the other. There are some
> examples in Bugzilla, where x87 is way faster (for some problems, as in
> PR 19780),
It just so happens that with 4.1 pr19780 with -m32 SSE math is a bit
faster (on a amd64 machine).
> so artifically limiting the compiler to SSE just because "x87 should
> die" is like shooting yourself in the foot. And a bit of competition
> never hurts ;)
I agree that not allowing i387 code for -m64 is an artificial limitation.
But I don't agree that we should complicate the backend for lifting that
limitation, which right now would be of dubious value. Most certainly we
should not make -mno-sse alone change the x86-64 ABI to an inferior
version. That we did so with -mno-80387 for -m32 is no reason to repeat
that, at least we there change to a saner ABI. Never change an ABI
lightly. So, perhaps this all would be a bit more convicing with a
benchmark showing some significant improvement when using x87 math and
passing conventions, instead of reviving x87 and just hoping that it
eventually will have some use, somewhen, somewhere, for someone.
> BTW: For my particular field of interest (processing real-world data),
> there is no need for strict IEEE compatibility as data is always in the
> same magnitude, and arguments to trigonometric functions are always less
> than <something>^38 ;). Infinities would mean that something went
> terribly wrong, so -ffast-math suits here perfectly. As measured data
> has uncertainty of +-1%, ulps are not something to worry about. However,
> 10% gain in speed (achievable with --ffast-math) means that calculations
> would finish half a day earlier.
Well, then you should be cheerful that you have 16 SSE registers in -m64
mode, and that -ffast-math works there too. That most probably will setup
any gain you can reach by using x87 math.