[cfe-commits] [PATCH] atomic operation builtins, part 1

[John McCall]

On Oct 12, 2011, at 9:03 AM, Jeffrey Yasskin wrote:
> On Wed, Oct 12, 2011 at 6:31 AM, Andrew MacLeod <amacleod at redhat.com> wrote:
>> - language atomic types up to 16 bytes should be padded to an appropriate
>> size, and aligned properly.
>> - if memory matching one of the 5 'optimized' sizes isn't aligned properly,
>> results are undefined.
>> - if the size does not match one of the 5 specific routines, then the
>> library generic ABI can handle it.  There's no alignment guarantees, so I
>> presume it would end up being a locked implementation using hash tables and
>> addresses or something.
> 
> The ABI library needs to demand alignment guarantees, or have them
> passed in, or it won't be able to support larger lock-free sizes on
> new architectures.

How aggressive are you suggesting we be about this?  If I make this type atomic:
  struct { float values[5]; };
do we really increase its size and alignment up to 32 bytes in the wild hope that the architecture will add 32-byte atomics someday?  If so, what's the limit?  If not, why is 16 the limit?

Honestly, I don't think future-proofing against arbitrary new atomic instructions really makes any sense.  Even going up to 16 bytes (on architectures where that can't be done lock-free now) worries me a bit.

Rounding up also worries me, since the user has no control over the padding bytes, but they can still cause spurious failures on, say, compare-and-swap.

John.