On 31/03/15 08:13 -0700, Richard Henderson wrote:
On 03/31/2015 08:03 AM, Jonathan Wakely wrote:
On 31/03/15 07:54 -0700, Richard Henderson wrote:
On 03/31/2015 06:41 AM, Jonathan Wakely wrote:
This is the best I've come up with, does anyone have any better ideas
than the #else branch to hardcode alignment of 16-byte types to 16?
If there's no 16 byte type, are we convinced this matters? I mean, there isn't
a 16-byte atomic instruction for 32-bit x86 (or any other 32-bit cpu of which I
am aware). So we're forced to use a locking path anyway.
The C front end gives struct S { char s[16]; } 16 byte alignment...
Um, I'm pretty sure it doesn't.
struct S { char s[16]; };
int x = __alignof(struct S);
.type x, @object
.size x, 4
x:
.long 1
What you're interpreting as alignment for that struct is probably optional
*additional* alignment from LOCAL_ALIGNMENT or LOCAL_DECL_ALIGNMENT or
something.
Sorry for not being clear, I meant __alignof(_Atomic struct S) is 16.
And it matters most for the integral types, not arbitrary structs.
And if we do want the alignment, do we stop pretending with all the sizeof's
and alignof's and just use power-of-two size alignment for all of them, e.g.
min_align = ((size & (size - 1)) || size > 16 ? 0 : size)
Yeah, I wondered about that too. Joseph indicated there are targets
where C gives alignof(_Atomic X) != sizeof(X), which is why the target
hook exists, but maybe we can just not worry about those targets for
now.
Those targets have alignof < sizeof. So in a way we'd probably be doing them a
favor. I know for instance that CRIS is in this category, where most data is
all byte aligned, but atomics must be naturally aligned.
Aha, I wondered why CRIS overrides the atomic_align_for_mode hook when
it seemed to be giving them natural alignment anyway - I didn't
realise non-atomic types are only byte-aligned.
