This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]