[PATCH] D31516: Separate {Min, Max}AtomicLockFreeWidth from MaxAtomicInlineWidth

[Dan Gohman via Phabricator via llvm-commits]

sunfish created this revision.

Currently, clang uses the MaxAtomicInlineWidth to determine both whether atomics up to a certain size can be "inlined" (aka, not a libcall), and also whether those atomics are guaranteed to be always lock-free. This implicitly assumes that if, for example, a 32-bit atomic is guaranteed lock free, that 16-bit and 8-bit are also guaranteed lock free, because they're also less than the maximum.

WebAssembly's proposed design for atomics has a guarantee that 4-byte atomics are always lock-free, but not 2-byte or 1-byte atomics. One reason is that on MIPS at least, it's not clear from available documentation that doing a 32-bit ll+sc sequence to implement an 8-bit or 16-bit atomic is safe if there's a possibility that a non-atomic access could concurrently modify any of the other 24 or 16 bits, respectively.

Clang on MIPS uses ll+sc to implement 8-bit and 16-bit atomics, and declares that they are lock-free (as they are within the MaxAtomicInlineWidth). It appears to do similar things on other targets.

Does clang know that this is always safe to do on MIPS and other targets? If there's documentation guaranteeing this, it would be desirable to feed this information back to the WebAssembly community so that the atomics proposal can be updated to reflect this.

Alternatively, if it's not safe, the attached patch may be useful. It introduces MinAtomicLockFreeWidth and MaxAtomicLockFreeWidth and uses it in the WebAssembly target to limit it to only 32-bit lock-free atomics. Possibly it would be appropriate to make MIPS and other targets use this too, however I have not yet made such changes.


Repository:
  rL LLVM

https://reviews.llvm.org/D31516

Files:
  include/clang/Basic/TargetInfo.h
  lib/AST/ExprConstant.cpp
  lib/Basic/TargetInfo.cpp
  lib/Basic/Targets.cpp
  lib/Frontend/InitPreprocessor.cpp
  test/Preprocessor/init.c

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D31516.93562.patch
Type: text/x-patch
Size: 15983 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170330/2f083340/attachment.bin>