lkml.org 
[lkml]   [2009]   [May]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Disable generation of sse3 instructions in kernel build.
[sending again with linux-kernel cc. Please don't drop cc list like this]

> On Mon May 11 2009, you wrote:
> > "Michael S. Zick" <lkml@morethan.org> writes:
> >
> > > Ref: 2.6.30-rcX
> > > The option to disable sse3 instructions needs to be added to build system for x86.
> > > Otherwise strange and mysterious things happen (tm).
> >
> > Can you please expand a little bit? With what compiler version did you
> > see problems? And in what area did they happen?
> >
>
> Sorry about the comment - it was based on the preceding code comment - perhaps now outdated.

It's not outdated. I wrote it originally.

>
> Once upon a time, the kernel did not touch the co-processor registers (any style of them) on x86 -
> see the preceding code comment and existing contents of the flag line being changed.
>
> If the kernel now saves/restores the co-processor registers - then only the code comment needs
> to be changed and the existing contents of the flag line be brought into line.

No the kernel doesn't do that. At least not automatically.

The reason these options are there is that at least some older gcc versions had
corner cases where they could generate instructions to touch MMX or SSE registers
even when the code doesn't use any floating point. That's why these options
were originally added to make sure this doesn't happen in the kernel,
where it would corrupt user data or crash.

But sse3 is just an extension of sse2 and when sse2 is enabled then
sse3 should be implicitely too. Unless some gcc version is really broken in this
regard, but I hope not. That is why I was asking if you've actually
seen failures from this.

Apparently you did not though. So your patch is not needed.

-Andi

--
ak@linux.intel.com -- Speaking for myself only.


\
 
 \ /
  Last update: 2009-05-12 08:49    [W:0.070 / U:0.536 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site