public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <andi@firstfloor.org>
To: "Michael S. Zick" <lkml@morethan.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Disable generation of sse3 instructions in kernel build.
Date: Tue, 12 May 2009 08:51:05 +0200	[thread overview]
Message-ID: <20090512065104.GC19296@one.firstfloor.org> (raw)
In-Reply-To: <200905111847.46187.lkml@morethan.org>

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

      parent reply	other threads:[~2009-05-12  6:45 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-10  0:03 Disable generation of sse3 instructions in kernel build Michael S. Zick
2009-05-11 21:16 ` Andi Kleen
     [not found]   ` <200905111847.46187.lkml@morethan.org>
2009-05-12  6:51     ` Andi Kleen [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090512065104.GC19296@one.firstfloor.org \
    --to=andi@firstfloor.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkml@morethan.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox