[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