Unify kernels for basic and nested affine for loop #217
Conversation
| namespace mlir { | ||
| namespace hcl { | ||
|
|
||
| bool compareAffineExprs(AffineExpr lhsExpr, AffineExpr rhsExpr) { |
There was a problem hiding this comment.
One question, did you do canonicalization somewhere? If I pass in d0+1 and 1+d0, will this function return true?
There was a problem hiding this comment.
One question, did you do canonicalization somewhere? If I pass in
d0+1and1+d0, will this function return true?
Yeah, I think that would be an issue for now. As I commented "Todo" in compareAffineMaps function, this is now a temporary solution. I was thinking about use a evaluation strategy to match some more sophisticated case as you mentioned. I will test and see how it work in future pr.
| static MlirModule UnifyKernels(MlirModule &mlir_mod1, MlirModule &mlir_mod2, | ||
| MlirContext &mlir_context) { |
There was a problem hiding this comment.
It's a bit weird that we pass in MLIRContext as the third argument. Can we make it a return module? Otherwise, providing some comments here describing what this mlir_context argument means is necessary.
There was a problem hiding this comment.
It's a bit weird that we pass in MLIRContext as the third argument. Can we make it a return module? Otherwise, providing some comments here describing what this
mlir_contextargument means is necessary.
For now, I'm thinking in the frontend, we will create a context and use it to create module1 and module2. Then, we called this primitive. This third argument is definitely removable, because we can just extract the context of module1, which will be the same context. We can modify this interface later according to our design choice.
Create a MLIR level unify functionality for two kernels. Merge the same affine for loop and use conditional branch to support different logic.