This is the mail archive of the
mailing list for the GCC project.
RE: -mno-sse and -mno-sse2 broken on opteron?
- From: "Dave Korn" <dave dot korn at artimi dot com>
- To: <joel dot sherrill at OARcorp dot com>,"'Marcin Dalecki'" <martin at dalecki dot de>
- Cc: "'Richard Henderson'" <rth at redhat dot com>,"'Steve Kargl'" <sgk at troutmask dot apl dot washington dot edu>,"'Andreas Jaeger'" <aj at suse dot de>,<gcc at gcc dot gnu dot org>,"'Andrew Pinski'" <pinskia at physics dot uc dot edu>
- Date: Fri, 7 Jan 2005 13:29:08 -0000
- Subject: RE: -mno-sse and -mno-sse2 broken on opteron?
> -----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
> >>> 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
> 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.
Can't think of a witty .sigline today....