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

[Matt Arsenault via Phabricator via llvm-commits]

arsenm 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:
> 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
Is it then disallowed to merge any calls that aren't nosync? e.g.

```
if (foo)
  bar(x) readnone
else
  bar(y) readnone
  
```

is no longer legal to combine these as

```
  
bar(foo ? x : y) readnone
  
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D62766