[PATCH] D93189: Introduce the `!nocapture` metadata and "nocapture_use" operand bundle
Johannes Doerfert via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Fri Jan 8 07:50:51 PST 2021
jdoerfert added inline comments.
================
Comment at: llvm/test/Transforms/InstCombine/nocapture_use.ll:42
+ %tmp4 = bitcast i32* %local to i8*
+ ret i32 %tmp2
+}
----------------
aqjune wrote:
> jdoerfert wrote:
> > 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.
> I meant whether this is UB or not:
> ```
> define i8* @f(i8* nocapture %p) {
> ret i8* %p
> }
> ```
> I think it should be UB, but this doesn't seem to be explicit in LangRef.
>
> nocapture_maybe_returned seems great..! I believe many library calls like memcpy can have this attached to their arguments. :)
> nocapture_maybe_returned seems great..! I believe many library calls like memcpy can have this attached to their arguments.
Yep, and almost every function that has the `returned` attribute on a pointer argument. Right now we assume such calls capture which is bad. Whoever introduces the enum version should replace the string version in the Attributor.
> I meant whether this is UB or not:
> ```
> define i8* @f(i8* nocapture %p) {
> ret i8* %p
> }
> ```
> I think it should be UB, but this doesn't seem to be explicit in LangRef.
Right. UB seems proper as there is no "value we could poison". I added an UB sentence to the new lang ref additions but not to the original nocapture attribute definition. Feel free to do so.
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