[llvm langref] inaccessiblemem implies nosync

[hiraditya]

Summary

As mentioned in:
https://github.com/llvm/llvm-project/issues/45555#issuecomment-981029204

[jdoerfert]

inaccessiblemem takes an access "kinds" which changes the behavior a lot. Is nosync implied by inaccessiblemem: none, or by inaccessiblemem: write, or both?

That said, we have nosync, people should just add it. This patch would cause all places that interpret nosync to also look for other things, which is not helpful at all.
If you want this behavior w/o the complex semantic, add nosync to all intrinsics and known functions we have right now. The rest is deduction.

[nikic]

TBH I find the semantics of nosync to be unclear to the point of uselessness, and I'm not sure whether this patch helps clarify them any.

I think the two clarifications to nosync that would help are:

• The memory effects of a synchronizing operation include all memory effects that the synchronization can make visible. For example, a synchronizing operation that can make previous writes to a location visible must have a write memory effect for that location.
• A synchronizing operation that imposes an ordering constraint with other synchronizing operations must perform a read and write to inaccessible memory.

I think this matches how LLVM models synchronization, but I was never able to get really satisfactory answer to this.

llvm/docs/LangRef.rst

``memory(...)``
     The supported memory location kinds are:
 
     - ``argmem``: This refers to accesses that are based on pointer arguments
       to the function.
     - ``inaccessiblemem``: This refers to accesses to memory which is not
       accessible by the current module (before return from the function -- an
       allocator function may return newly accessible memory while only
       accessing inaccessible memory itself). Inaccessible memory is often used
-      to model control dependencies of intrinsics.
+      to model control dependencies of intrinsics. Note that `inaccessiblemem`
+      implies `nosync`.
     - The default access kind (specified without a location prefix) applies to
       all locations that haven't been specified explicitly, including those that
       don't currently have a dedicated location kind (e.g. accesses to globals
       or captured pointers).
 
     If the ``memory`` attribute is not specified, then ``memory(readwrite)``
     is implied (all memory effects are possible).