[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