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

["Dave Korn" <dave dot korn at artimi dot com>]

> -----Original Message-----
> From: gcc-owner On Behalf Of Joel Sherrill 
> Sent: 07 January 2005 12:32

> 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.

> >> 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.

> > 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.

  It's also a major issue for ppc platforms.  Saving and restoring all those
altivec registers is a BIG hit and absolutely not something you want to do in
low-latency-high-priority interrupt handlers, or indeed as part of your standard
syscall entry sequence, if you can possibly avoid it.

> 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.

> 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/*.

  Indeed.  While it's always possible to specify that a kernel has to be
compiled with whatever options are required to inhibit the compiler from this
behaviour, it's hard to impose similar standards on what flags end-users develop
their apps using; hence if the compiler can't be configured to default to not
use these registers for the particular target/arch in question, almost all
user-land apps will end up using them, and the kernel will have no opportunity
for opportunistically lazy context switching anyway.


    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....