Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Address comment
mlir/lib/Dialect/SCF/SCF.cpp | ||
---|---|---|
1289 | I think the condition you mention isn't quite sufficient, but ensuring the second if doesn't use the result of the first if should be sufficient. Adding a note that this can be extended to support that. |
mlir/lib/Dialect/SCF/SCF.cpp | ||
---|---|---|
1289 | Actually neither the then or the else branch should use the result indeed. |
mlir/lib/Dialect/SCF/SCF.cpp | ||
---|---|---|
1308–1310 | You have a getUsers() on Operation which allows to directly iterates on this nested loop (see inline edit) | |
1313 | Nit: no need for braces here. | |
1318 | (spurious braces) and you can likely just assign() here: mergedTypes.assign(nextIf.getResultTypes().begin(), nextIf.getResultTypes().end()); | |
1326 | rewriter.mergeBlocks will do the splicing, but at the end. | |
1329 | Nit: .front() would avoid derefencing an iterator (may just be more readable) | |
1338–1340 | ||
1363 | Just like the other revision: there are far too much back() (and even back().back()!) here, I'd like to see some refactoring into better accessors. | |
1366–1368 | ||
1385 | Can you use llvm::enumerate instead of a side indexing? |
mlir/lib/Dialect/SCF/SCF.cpp | ||
---|---|---|
1343 | Ah OK I see the logic, it is actually moving and preserving the block itself. And we need this because the else region can be empty but not the then one. |
The restriction on the first if isn't intrinsic to the fusion right? We could fuse the two even if they both return results, as long as the else branch of the second does not use a result of the first if I think.