This is an archive of the discontinued LLVM Phabricator instance.

Make check for atomic alignment target dependent
AbandonedPublic

Authored by vchuravy on Dec 10 2016, 5:28 AM.

Details

Reviewers
craig.topper
Summary

The goal is to relax the alignment check for the X86 architecure
restoring the behaviour exhibited by LLVM 3.8 and GCC.

According to the Intel Architectures Software Developer’s Manual, Volume 3A:

The integrity of a bus lock is not affected by the alignment of
the memory field. The LOCK semantics are followed for as many bus cycles
as necessary to update the entire operand. However, it is recommend that
locked accesses be aligned on their natural boundaries for better
system performance

also see http://joeduffyblog.com/2006/12/06/clr-data-alignment-and-cmpxchg8b/

Atomics operations like CMPXCHG16B for i128 do need to be naturally aligned.

Patch by: Valentin Churavy

Event Timeline

vchuravy updated this revision to Diff 80999.Dec 10 2016, 5:28 AM
vchuravy retitled this revision from to Make check for atomic alignment target dependent.
vchuravy updated this object.

Ref https://gcc.gnu.org/ml/gcc/2016-11/txt6ZlA_JS27i.txt .

While the instruction may guarantee atomicity without requiring alignment, I think there's still question whether the platform ABI (i.e. libatomic ABI linked above) allows it. I did not find any clear mention of the inlineability of unaligned i64 atomic on 32bit x86 but it does include other examples where the atomic is not inlineable when it's not properly aligned (e.g. in the _Atomic struct section).

Given that the draft is more or less a documentation and refinement of the current libatomic + clang/gcc behavior, I just checked what does it do on 32bit x86 for a 4bytes aligned i64 and it seems to be using the locking path. Unless that is changed and required, inlining 4bytes aligned i64 atomic will likely violate the libatomic ABI.

vchuravy abandoned this revision.Jan 2 2017, 6:25 PM