Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

clang shouldn't use aligned SSE instructions on 32bit x86 linux #21788

Open
nico opened this issue Oct 30, 2014 · 4 comments
Open

clang shouldn't use aligned SSE instructions on 32bit x86 linux #21788

nico opened this issue Oct 30, 2014 · 4 comments
Labels
backend:X86 bugzilla Issues migrated from bugzilla

Comments

@nico
Copy link
Contributor

nico commented Oct 30, 2014

Bugzilla Link 21414
Version trunk
OS All
CC @DimitryAndric,@emaste,@zmodem,@hfinkel,@rnk,@TNorthover

Extended Description

We recently enabled clang as default compiler for chrome on linux. It mostly went well. One problem we ran into was that chrome 38 crashed on old debians. rnk explained this to me, and from what I understand (I probably got some of it wrong) it was due to clang using aligned SSE instructions.

gcc changed their alignment abi on linux a while ago, and the current abi does guarantee alignment. The old one doesn't, and I suppose on debian system libraries still use the old abi. gcc emits unaligned SSE loads on 32bit linux, clang should too.

As is, every provider of binary-distributed binaries on linux will run into this and then work around it somehow. We ended up adding tons of stack adjustments, which bloats binary size, is bad for the icache, etc. Unaligned SSE reads are almost as fast as aligned ones, so clang should do the thing that Just Works instead of giving a bad user experience to its users.

https://code.google.com/p/nativeclient/issues/detail?id=3935

@DimitryAndric
Copy link
Collaborator

Since bug 8969, 32-bit Linux assumes a 16 byte aligned stack. Upstream gcc also defaults to this, so why would it ever choose unaligned SSE loads?

@nico
Copy link
Contributor Author

nico commented Oct 30, 2014

See comment 0. Binaries built with old gccs don't conform to this abi, so gcc uses unaligned reads to be abi compatible with old versions of itself.

@rnk
Copy link
Collaborator

rnk commented Oct 30, 2014

See comment 0. Binaries built with old gccs don't conform to this abi, so
gcc uses unaligned reads to be abi compatible with old versions of itself.

I think it's a little more nuanced than that, here's the history as I understand it:

  • Long ago (2006?) gcc increased the "preferred" stack alignment to 16.
  • They waited a while with this setting
  • In the next release, they began assuming the stack was 16 byte aligned.
  • Users reported bugs, and their compromise solution was "we'll keep assuming 16 byte alignment, but we'll use unaligned loads and stores so that users stop filing bugs on us"

I don't consider it correct to say that they are ABI-compatible with old GCC binaries. It's just that they have made an engineering tradeoff to avoid the most obvious forms of breakage for people on systems that aren't using the new ABI.

I think, in retrospect, we should probably also make this compromise. It's the practical thing to do.

See also:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

If you follow the breadcrumbs, it looks like GCC started aligning the stack back in 2006:
https://gcc.gnu.org/ml/gcc-patches/2006-09/msg00252.html

@rnk
Copy link
Collaborator

rnk commented Oct 30, 2014

Also, to be absolutely clear, this is for 32-bit x86 Linux, not x86_64 which has always had a 16-byte stack alignment requirement in the ABI.

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 9, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backend:X86 bugzilla Issues migrated from bugzilla
Projects
None yet
Development

No branches or pull requests

3 participants