Open Quuxplusone opened 10 years ago
Bugzilla Link | PR18006 |
Status | NEW |
Importance | P normal |
Reported by | Rafael Ávila de Espíndola (rafael@espindo.la) |
Reported on | 2013-11-20 10:13:03 -0800 |
Last modified on | 2014-01-07 10:25:04 -0800 |
Version | unspecified |
Hardware | PC All |
CC | benny.kra@gmail.com, llvm-bugs@lists.llvm.org, rnk@google.com |
Fixed by commit(s) | |
Attachments | |
Blocks | |
Blocked by | |
See also |
About the stack alignment:
I only noticed that given
void g(char *);
void f(int n) {
char v;
g(&v);
}
gcc will create a " subq $24, %rsp", indicating that it is trying to keep
the stack 32 bytes aligned, but I don't know of any intrinsic that would
require a 32 byte alignment to test if gcc assumes such alignment.
I suspect that after a few releases they will start assuming the stack is 32-byte aligned, just like they assume it is 16-byte aligned with -m32 today, despite the fact that the SysV ABI doesn't guarantee that. =P
Testing with
void f(char*);
void g(void) {
char v[32];
f(v);
}
shows that gcc produces a "subq $40, %rsp" and no realignment, so it is only
keeping the stack object aligned to 16 bytes.
The differences we have compared to gcc are only for static data (both 32 and
64 bit modes): Objects >= 32 bytes are aligned to 32 bytes. This is true for
both arrays and structs. For example 'x' is 32 byte aligned in
struct foo {
uint64_t a;
uint64_t b;
uint64_t c;
uint64_t d;
};
foo x;
While gcc doesn't implement it, it would probably also be profitable (according
to the intel optimization manual Rule 46 and Rule 75) to align all static
objects >= 64 bytes to 64 bytes and smaller object to the previous power of two.