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

[Philip Reames via Phabricator via llvm-commits]

reames added a comment.

In D56534#1362134 <https://reviews.llvm.org/D56534#1362134>, @jfb wrote:

> In D56534#1362128 <https://reviews.llvm.org/D56534#1362128>, @jyknight wrote:
>
> > In D56534#1362115 <https://reviews.llvm.org/D56534#1362115>, @efriedma wrote:
> >
> > > > The contract for the atomic library is that it _MUST_ do a lock-free operation on an object on which _any_ compiler in use on the system may have emitted a lock-free operation for.
> > >
> > > That's not really relevant.  The question is what happens if, one on thread, I perform a 4-byte operation at address p, and then on another thread, I perform a 4-byte atomic operation on address p+2.
> >
> >
> > OK. Certainly no guarantees can be made in such a case.
> >
> > But, relatedly -- and more subtly -- I also expect there'll be no guarantee of correct behavior if you mix 2-byte and 4-byte naturally-aligned accesses to some address p.
>
>
> Going further: this is an active field of research, and *architectures* don't provide meaningful guarantees when mixing alignments and / or sizes. I doubt it's useful for LLVM to provide guarantees either. I agree that we want to try to always do lock-free where we can, and be consistent about where we do non-lock-free.


I think there's an important correction that needs made here.  It's correct to say that not all architectures provide guarantees for mixed alignment and sizes.  It is incorrect to say that no architecture does, or that some architectures don't provide clear behaviour in practice.

My general feeling from the above discussion is that we are going to *have to* make some of this target defined.  We may be able to provide a guarantee of minimal functionality, but we should not disallow a target from providing stronger guarantees.


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

https://reviews.llvm.org/D56534