[LangRef] asm clobber constrains: '~memory' allows reads and synchronization

[RalfJung]

Cc @nikic -- does this sound right? I was not sure what the best way is for talking about "synchronization effects".

[llvmbot]

@llvm/pr-subscribers-llvm-ir

Author: Ralf Jung (RalfJung)

Changes

Cc @nikic -- does this sound right? I was not sure what the best way is for talking about "synchronization effects".

---

Full diff: https://github.com/llvm/llvm-project/pull/150191.diff

1 Files Affected:

• (modified) llvm/docs/LangRef.rst (+7-4)

diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index bac13cc0424a6..9f792fa392cca 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -5448,10 +5448,13 @@ Clobber constraints
 A clobber constraint is indicated by a "``~``" prefix. A clobber does not
 consume an input operand, nor generate an output. Clobbers cannot use any of the
 general constraint code letters -- they may use only explicit register
-constraints, e.g. "``~{eax}``". The one exception is that a clobber string of
-"``~{memory}``" indicates that the assembly writes to arbitrary undeclared
-memory locations -- not only the memory pointed to by a declared indirect
-output.
+constraints, e.g. "``~{eax}``".
+
+The one exception is that a clobber string of "``~{memory}``" indicates that the
+assembly reads and writes arbitrary undeclared memory locations -- not only the
+memory pointed to by a declared indirect output. Furthermore, the assembly may
+also cause synchronization with other threads, such as via release/acquire
+fences and atomic memory accesses.
 
 Note that clobbering named registers that are also present in output
 constraints is not legal.

[efriedma-quic]

See also #110510 .

Maybe we should explicitly state this is a superset of "sideeffect", since synchronizing with other threads basically allows arbitrary effects.

Do you anticipate any transforms need to be changed based on this?

[RalfJung]

Maybe we should explicitly state this is a superset of "sideeffect", since synchronizing with other threads basically allows arbitrary effects.

Do you mean the llvm.sideffect intrinsic? That is inaccessiblememonly so it's way less than what we want here, seems potentially confusing to reference that.

Do you anticipate any transforms need to be changed based on this?

This boils down to whether any transform considers asm blocks with this clobber to be nosync. I would hope that's not the case...

[efriedma-quic]

Do you mean the llvm.sideffect intrinsic

I mean call void asm sideeffect ""()

[RalfJung]

Ah, I see.

Purely formally I could imagine sideffect and ~memory being entirely orthogonal. But I'm not sure if that would actually be practically useful. Do analyses currently treat ~memory as basically implying sideeffect?

[efriedma-quic]

Before isel, it looks like the only place that actually explicitly reasons about "sideffect" markings on inline asm is llvm/lib/Transforms/IPO/AttributorAttributes.cpp. which effectively uses the lack of it to infer the "norecurse" attribute. Everything else just sort of ignores the fact that it's an inline asm, and assumes the frontend will set appropriate attributes on the call.

So as a practical matter, I'm not sure how much the formal rules matter here, if nothing is actually going to reason using them.