[PATCH] D56534: [Verifier] Add verification of unaligned atomic load/store

[James Y Knight via Phabricator via llvm-commits]

jyknight added a comment.

In D56534#1363956 <https://reviews.llvm.org/D56534#1363956>, @reames wrote:

> Again, I would strongly resist any effort to define away overlapping atomics or unaligned atomics.  This works today in practice on common architectures.  We are reliant on this implementation working as it does today for overlapping atomics.


In LLVM IR, we have some clear answers:

- Perfectly-overlapping accesses -- no matter what their alignment -- are safe. We can and do support correct unaligned access via lowering to an appropriate libcall (which may use a lock).
- Partially-overlapping accesses of the same size, but offset by some bytes is definitely not safe. (due to potentially mixing locked and native atomics).
- A mixture of access sizes where any may be too large to be lock-free is definitely not safe. (same reason)

And then the hard question: A set of mixed-size accesses, where each is naturally-aligned and lock-free.

I would prefer if we could define away atomicity guarantees in the face of such accesses as well.  While we may be able to carve out and define some cases where it is safe, if there's no great reason to, it would be far simpler not to.

> Specifying that away because we happen to not be able to guarantee anything on other platforms is not acceptable.
> 
> Now, to be clear, I'm not arguing we can't change *spelling*.  If you want to insist that overlapping atomics be done via intrinsics, I'll still argue with you because I think it's a bad design, but it's not a fundamental non starter like defining away existing target behaviour is.

I assume you're now talking about IR generated from a frontend, not simply the internal handling of the element-wise mem intrinsics, correct?  Can you explain more about what is reliant on the ability to do overlapping/mixed-size atomic accesses? What kinds of access patterns are you depending on? (e.g. what alignments, sizes, and memory orderings).


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56534/new/

https://reviews.llvm.org/D56534