This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: -mno-sse and -mno-sse2 broken on opteron?
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