Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
mlir/include/mlir/IR/FunctionInterfaces.td | ||
---|---|---|
89 ↗ | (On Diff #421396) | Could the changes in this file be split to a separate patch? (Or just pushed as an NFC...) |
mlir/include/mlir/IR/FunctionInterfaces.td | ||
---|---|---|
89 ↗ | (On Diff #421396) | Thanks - meant to do that but forgot. Will split before landing. |
mlir/include/mlir/Dialect/MLProgram/IR/MLProgramOps.td | ||
---|---|---|
170 | what does "terminator" mean for a graph region? Can you just remove it (it also says "terminates a subgraph" below too. | |
174 | nit: remove "function" from this, to avoid confusion. or is the idea that subgraph and func are both "functions"? | |
mlir/lib/Dialect/MLProgram/IR/MLProgramOps.cpp | ||
72 | nit: not sure if "returns" is the most consistent nomenclature here. Maybe "has N results"? | |
76 | same comment about "return" |
mlir/include/mlir/Dialect/MLProgram/IR/MLProgramOps.td | ||
---|---|---|
170 | In tensorflow, TFG Functions are graph region but the FuncOp verifier enforces that there is a terminator still (the FuncOp return) |
Nice!
mlir/include/mlir/Dialect/MLProgram/IR/MLProgramOps.td | ||
---|---|---|
40 | Grammar nit: it cannot represented nested symbols. | |
65 | plz fit to 80 cols here and below | |
79 | Are these provided by FunctionOpInterface now? | |
170 | I'm not sure what Sean means here: a terminator is the same in a graph region as a CFG region: it is the last operation in the block. This is important even though "order of execution" isn't generally a thing in graph regions. You still need a canonical place to put it, just like how LLVM puts PHIs at the top of a block. |
Nice :-)
mlir/include/mlir/Dialect/MLProgram/IR/MLProgramOps.td | ||
---|---|---|
15 | If you added the infer return type interface this should result in some simpler builders be generated too I believe (just looking at signatures) | |
32 | s/An f/F/ ? | |
174 | OOC why `` around subgraph (here and above)? It doesn't variable or accessor and subgraph is well established term in graph theory (I find it common enough to be akin to function in needing special markers) | |
203 | (for later discussion) I will mention that we found exact matching quite cumbersome during progressive lowering and optimizations. For one it doesnt match the ML frameworks we were working with and so we had casts that weren't needed by the system (and in this case it means one would probably only partially use ML program dialect and only post rounds of high level optimizations rather than introduce it early). One ends up inserting numerous casts to appease the type system, these may then obscure other pattern matches (while the ops interacting are perfectly happy with compatible types) and one ends up invoking shape inference more times than needed to identify and nuke unneeded casts (while some casts may have performance impact due to device assignment in distributed workload, so it isn't always simple removal). | |
mlir/lib/Dialect/MLProgram/IR/MLProgramDialect.cpp | ||
2 | Nit: MLIR feels redundant here. | |
mlir/lib/Dialect/MLProgram/IR/MLProgramOps.cpp | ||
99 | (I'd almost be tempted to do llvm::enumerate combined with zip here, but would need to try to see how readable) |
mlir/include/mlir/Dialect/MLProgram/IR/MLProgramOps.td | ||
---|---|---|
170 | Oh, I think I must have been confusing graph regions with the "region doesn't need to have a terminator" support that Mehdi added for ModuleOp. Sorry for the noise. |
Can you add a pass / reusable pattern that converts ml_program.func to func.func and the reverse? Otherwise I feel like we are going to roll that many times downstream just for our initial push in IREE (can be a separate patch of course).
Hi folks - thanks for the reviews and sorry to leave this idling. I came down with covid last week and am just getting back online. Will address comments and move this forward soon.
mlir/include/mlir/Dialect/MLProgram/IR/MLProgramOps.td | ||
---|---|---|
15 | Really? Even though none of these ops have return types? | |
65 | Oops. Thanks. Used to formatters/linters :/ | |
79 | No, they are just declarations on that interface. | |
203 | I thought about this and opted to do this for now and discuss further. Completely open to broadening in a followup. | |
mlir/include/mlir/IR/FunctionInterfaces.td | ||
89 ↗ | (On Diff #421396) | Split into https://reviews.llvm.org/D123757 |
mlir/lib/Dialect/MLProgram/IR/MLProgramOps.cpp | ||
72 | Thanks - copypasta. Updated here and below. | |
99 | I got this from func.return so we should probably update there if we come up with something more readable. I don't have an opinion. Per your other comment, we're likely going to re-evaluate the verification behavior anyway, which will mean rewriting this. |
If you added the infer return type interface this should result in some simpler builders be generated too I believe (just looking at signatures)