IR and parsing changes to allow yield semantics similar to SCF for affine.if, and to provide a method to perform reductions via affine.parallel. Currently this commit does not modify lowering for affine.if (although lowerings for affine.if that do not yield values are still correct). Additionally, affine.parallel does not currently have a lowering.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Please re-upload with full context.
https://llvm.org/docs/Phabricator.html#requesting-a-review-via-the-web-interface
mlir/include/mlir/Dialect/StandardOps/IR/StandardOpsBase.td | ||
---|---|---|
2 | Please make sure that all lines are wrapped at 80 characters. For this line specifically, you need to shorten it and not wrap. | |
mlir/lib/Dialect/Affine/IR/AffineOps.cpp | ||
1916 | Please drop trivial braces, also why can't you just do result.addTypes(resultTypes)? | |
1923 | nit: Please use builder.createBlock instead. | |
1929 | Same here. | |
1937 | nit: Add a parameter comment(/*...=*/ for the {}) | |
2433 | nit: Drop this comment, the code is self-explanatory. | |
2434 | Same comment as above. | |
2439 | nit: Please spell out the type instead of auto, and drop the trivial braces. | |
2442 | nit: The code is self-explanatory, so this comment can be dropped. Also, please use complete sentences in comments with correct grammar/punctuation. | |
2467 | nit: Spell out auto here. | |
2535 | Please drop these trivial braces, here and throughout the commit. | |
2539 | nit: Spell out auto here. | |
2562 | Drop the mlir:: here and many other places. | |
2564 | Please do not use replaceAllUsesWith directly, use the pattern rewriter instead. | |
2783 | Please do not use e as an iteration variable, it is very confusing. |
mlir/lib/Dialect/Affine/IR/AffineOps.cpp | ||
---|---|---|
2548 | The canonicalization really feels like it should be in a separate revision? |
Code review changes from flaub, and removed additional canonicalizations which are unrelated to the IR change for a separate diff later.
Thanks Jeremy! Some minor comments.
mlir/include/mlir/Dialect/Affine/IR/AffineOps.td | ||
---|---|---|
540 | Since this is about SSA value reductions, should we rename "AtomicRMWKind" to something that doesn't imply memory or an atomic implementation? These reductions could be implemented following different approaches, not only using atomic ops, right? Maybe ReductionKind would work? | |
545 | I'm trying to understand if this is intended to achieve the same as scf.reduce.return. Couldn't we do something similar and keep both SCF and Affine aligned? Or is this intentionally different for some reason? | |
607 | I would suggest using 'reduction' terminology instead of aggregates, to align with scf, OpenMp, and others. | |
mlir/lib/Dialect/Affine/IR/AffineOps.cpp | ||
2730 | Same. I would suggest reduce/reduction to align terminology with scf, OpenMp and others. |
mlir/include/mlir/Dialect/Affine/IR/AffineOps.td | ||
---|---|---|
540 | I do think ReductionKind would be a better name, but I wanted to minimize unrelated changes such as in atomicrmw, so I was considering do a NFC commit afterwards for both atomicrmw and affine.parallel. Actually, I was considering if it might be good to rename atomicrmw to atomic_reduce or something similar since there is already another more general atomic rmw that has an arbitrary interior and is typically lowered though atomic compare and exchange, and the enum based one is all reductions. | |
545 | SCF uses a somewhat more general mechanism for reductions, but that adds a fair amount of complexity, in particular regarding initialization. I'd rather keep reductions for affine.parallel to be a closed set with known identity elements until we have a reason not to, since it's easier to pattern match to specialized hardware, and makes a number of the transforms easier as well. In practice this set of reduction operations seems to cover all of the ML use cases we've run into. | |
607 | Totally agree, I will rename. |
It's nice to see this. Sorry about the delay - I missed this patch. I think this is an important design update to be mentioned on discourse. Could you please post a note there - just the op doc descriptions + the example snippets you have here should be sufficient to start with.
mlir/include/mlir/Dialect/Affine/IR/AffineOps.td | ||
---|---|---|
307–312 | Missing doc description here on the meaning on the yield operands. Note that the semantics of the terminator depend on the parent op holding it, and so this has to be described here. Please also update the example to include affine.yield. |
Could you please add a single line guard in hoistAffineIfOp with a TODO to bail out on any affine.if ops that have results? The loop unswitching will no longer be correct with such affine.if ops.
mlir/include/mlir/Dialect/Affine/IR/AffineOps.td | ||
---|---|---|
762–763 | This has to be marked ReturnLike. | |
mlir/lib/Conversion/AffineToStandard/AffineToStandard.cpp | ||
330 | Nit: Yield ops (terminators for affine regions) are removed. |
Could you please update the commit summary to reflect this revision? "reduce" isn't mentioned there. You can drop the "... I do not intend .." part from the summary. I think the last line is also outdated.
mlir/lib/Dialect/Affine/IR/AffineOps.cpp | ||
---|---|---|
2654 | Please avoid auto here. |
Update commit summary to say you are adding reduction support for affine.parallel?
mlir/include/mlir/Dialect/Affine/IR/AffineOps.td | ||
---|---|---|
339 | Nit: load -> affine.load (won't parse otherwise). |
Nit: I think the commit title could be shortened to start with "Add yield semantics ..." ('IR changes to' is obvious).
Missing doc description here on the meaning on the yield operands. Note that the semantics of the terminator depend on the parent op holding it, and so this has to be described here. Please also update the example to include affine.yield.