-mno-sse and -mno-sse2 broken on opteron?

[Joel Sherrill <joel@OARcorp.com>]

Marcin Dalecki wrote:
> 
> On 2005-01-07, at 00:41, Richard Henderson wrote:
> 
>> On Thu, Jan 06, 2005 at 08:44:36PM +0100, Marcin Dalecki wrote:
>>
>>> That's a non issue. You simply don't use floating point arithmetics
>>> when for kernels.
>>
>>
>> How naieve you are.  The compiler is getting smart enough to use
>> SSE for non floating-point applications.  While looking at a bug
>> the other week, I caught it doing exactly that with a bit of
>> kernel code.
> 
> 
> Then you are simply using a "different" definition of "floating point 
> register"
> then factual on the architecture at hand.
> 
>> If you're not either turning off sse, or saving and restoring all
>> sse state on entry to the kernel, then you risk data corruption.
> 
> 
> And you are 100% sure the cost of this will be higher then constraining the
> compiler to a defective API? If the compiler is going to use them for 
> purposes
> not associated necessarily with floating point calculations you will 
> find yourself in
> a situation where most of the user space will ask you indirectly to save 
> those
> registers on stack anyway... So what? You will soon give the trick of lazy
> floating point register file saving on context switch factually up and 
> pay the
> penalty of a constrained register file anyway.
> 

RTEMS distinguishes between integer only threads and those
that use floating point.  It then completely avoids saving the
FP context for integer only threads.  It also does the lazy
save trick and disables the FPU when possible architecturally.

On architectures where gcc has chosen to use FP registers
to optimize integer operations, RTEMS has in fact had to
treat the FP as part of the integer context.

It would really be nice if either gcc stuck with integer only
registers unless it is an "obvious" place to use FP or vector
registers.  Or let it be a target option to be "obvious" in the
use.  By non-obvious, I recall that one target gcc uses FP
multiply for an array offset calculation.  This is non-obvious.

I ask because for RTEMS and other gcc targets, this would
let us decide whether we want to save the extra context all the
time.

I am not arguing against this optimization only pointing out that
it forces run-time issues onto software not part of gcc.  Please
give us the flexibility to to decide to use it in gcc/config/*.

I'm prone to think that RTEMS would disable this type of optimization
in favor of gcc sticking to using the "obvious" register set.  We gain
more by minimizing and controlling context sizes. But this wouldn't be 
everyone's choice.

--joel




-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985