[PATCH] D76602: [MLIR] Introduce std.alloca op
Alex Zinenko via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Mon Apr 6 07:33:05 PDT 2020
ftynse added inline comments.
================
Comment at: mlir/include/mlir/Dialect/StandardOps/IR/Ops.td:329
+ The "alloca" operation allocates memory on the stack, to be automatically
+ released when the stack frame is discarded. The amount of memory allocated
+ is specified by its memref and additional operands. For example:
----------------
bondhugula wrote:
> ftynse wrote:
> > Could you please elaborate what is a stack frame in MLIR? We don't seem to have this concept defined anywhere. In particular, is it only related to `std.func`, or can one register other ops that create stack frames?
> A stack frame here refers to the standard stack frame concept in CS that we know of! It's up to the conversion out of MLIR to realize this correctly.
MLIR makes us rethink a lot of things. Like MLIR does not have functions as a first-class concept :) I could obviously guess your intention with stack frames, but I would still insist you think it through in context of MLIR. Similarly to functions, I don't think we have a built-in memory model that has a stack... Or that `std.func` semantics says something about stack frames. IIRC, this was one of the conceptual problems of having `alloca` in the first place.
What should happen if I do the following?
```
my.func @foo() {
alloca ...
}
```
Or
```
std.func @foo() {
%0 = my.func_that_may_or_may_not_be_a_lambda @inner() {
alloca ...
}
}
```
"Conversion out of MLIR" does not mean anything to me either. Do you mean the translation of LLVM dialect to LLVM IR? There are other passes that may be using the standard dialect that are completely unaware of that.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D76602/new/
https://reviews.llvm.org/D76602
More information about the llvm-commits
mailing list