[PATCH] D93189: Introduce the `!nocapture` metadata and "nocapture_use" operand bundle

Johannes Doerfert via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Jan 7 17:05:20 PST 2021


jdoerfert marked 2 inline comments as done.
jdoerfert added a comment.

In D93189#2485796 <https://reviews.llvm.org/D93189#2485796>, @aqjune wrote:

> I have a question - is it possible to have the same optimization power with !nocapture only? In other words, is it purely for making analysis flow-insensitive?

Hm. The two could be used in isolation but make most sense together. `!nocapture` only makes sense alone if you don't actually use the memory later, or the use is already "implied" otherwise. I don't have a use case for `"nocapture_use"(%ptr)` alone right now. It basically indicates a non-capturing use but I don't know why we would add one on it's own. 
Together they allow to weaken/demote an existing use. I'd be interested in ideas for standalone uses.

> We can define that it is undefined behavior for any function calls after this store to load the pointer and capture it.

That part is missing, right.



================
Comment at: llvm/test/Transforms/InstCombine/nocapture_use.ll:42
+  %tmp4 = bitcast i32* %local to i8*
+  ret i32 %tmp2
+}
----------------
aqjune wrote:
> (Orthogonal to this patch) would it be great to explicitly state in LangRef that it is illegal for a function call to return a nocapture pointer? I can make a super short patch for this. @nlopes was also interested in this when implementing nocapture in Alive2.
I'm not sure I understand.

FWIW, Attributor uses an internal attribute "nocapture_maybe_returned" for call arguments to improve nocapture analysis.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93189



More information about the llvm-commits mailing list