[PATCH] D74651: Add IR constructs for inalloca replacement llvm.call.setup

Arthur Eubanks via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Apr 20 14:38:50 PDT 2020


aeubanks added inline comments.


================
Comment at: llvm/docs/LangRef.rst:1069
+    The preallocated attribute requires a type argument, which must be
+    the same as the pointee type of the argument.
 .. _attr_inalloca:
----------------
efriedma wrote:
> Are there any rules for what value has to be passed to a "preallocated" argument?  Or is the value ignored?
It's ignored, clarified.


================
Comment at: llvm/docs/LangRef.rst:11939
+corresponding argument. The token must be the parameter to a
+``"preallocated"`` operand bundle for the corresponding call.
+
----------------
efriedma wrote:
> Probably worth mentioning the rules for nested llvm.call.preallocated.setup .
Added blurb about how

t1 = setup()
t2 = setup()
foo() [t2]
foo() [t1]

is ok but not


t1 = setup()
t2 = setup()
foo() [t1]
foo() [t2],

is that good enough?


================
Comment at: llvm/docs/LangRef.rst:11963
+the call associated with the ``%setup_token``, which must be from
+'``llvm.call.preallocated.setup``'.
+
----------------
efriedma wrote:
> Maybe worth mentioning what happens if you call llvm.call.preallocated.arg after the memory is deallocated?
Said it's UB if you call llvm.call.preallocated.arg after the call, or after another llvm.call.preallocated.setup.


================
Comment at: llvm/lib/IR/Verifier.cpp:4522
+  }
   case Intrinsic::gcroot:
   case Intrinsic::gcwrite:
----------------
efriedma wrote:
> Do you need to check that there aren't any calls to llvm.call.preallocated.arg with the wrong token?
Good catch, I missed that. Done and added test case.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74651





More information about the llvm-commits mailing list