[PATCH] D62766: [Attributor] Deduce "nosync" function attribute.

[Johannes Doerfert via Phabricator via llvm-commits]

jdoerfert added inline comments.


================
Comment at: llvm/docs/LangRef.rst:1476-1478
+    This function attribute indicates that the function does not communicate
+    (synchronize) with another thread. If the function does ever synchronize 
+    with another thread, the behavior is undefined.
----------------
jdoerfert wrote:
> arsenm wrote:
> > arsenm wrote:
> > > I think this is a bit vague. In particular I don't think the LangRef defines what a "thread" means anywhere. I also think this needs to be more clear on what kinds of synchronization is allowed. Is this only communication through some addressable memory? What about GPU cross lane communication operations?
> > > 
> > > I'm wondering if this is sufficient to solve this problem: http://lists.llvm.org/pipermail/llvm-dev/2013-November/067359.html
> > > TLDR, memory instructions can currently be hoisted over an arbitrary call if they are accessing a noalias argument
> > This is also mentioned as a proper attribute here (which I would greatly prefer to adding another string attribute), but only handled as a string attribute
> That is a good point. I was initially thinking string attributes are fine but D62784 seems to be stuck which makes the testing of them hard.
> 
> Long story short, lets make them enum attributes.
> 
> @sstefan1 could you please make this a proper enum attribute? This will require some additional "mechanics" in:
> `llvm/lib/AsmParser/LLParser.cpp`
> `llvm/lib/Bitcode/Reader/BitcodeReader.cpp`
> `llvm/lib/Bitcode/Writer/BitcodeWriter.cpp`
> `llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp`
> `llvm/lib/IR/Attributes.cpp`
> `llvm/lib/IR/Verifier.cpp`
> 
> Could be more though. Look for an existing attribute, e.g. Cold, and how that is handled.
> 
> 
> @uenoku Could you please also make `nofree` an enum attribute?
> I think this is a bit vague. In particular I don't think the LangRef defines what a "thread" means anywhere.

I did think/hope we do not have to. There is the implicit execution thread and `nosync` says there is "nothing else" while the function is executed. Basically, there are no side-effects that did not originate from the code we see. Please object if you think this is not sufficient.

> I also think this needs to be more clear on what kinds of synchronization is allowed. 

None, if `nosync` is present.

> Is this only communication through some addressable memory? What about GPU cross lane communication operations? 

I'd say, not allowed if `nosync` is present.

> TLDR, memory instructions can currently be hoisted over an arbitrary call if they are accessing a noalias argument

I tried to expose that lately [1] but failed, do you have an example?

[1] https://bugs.llvm.org/show_bug.cgi?id=41781


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D62766