Could you also update https://mlir.llvm.org/docs/DialectConversion/#type-conversion ?
Fri, Feb 14
Thanks River! I had prototyped a similar thing, but you've beaten me to it and added fancy templates :)
LGTM when extra documentation is added as discussed on Discourse.
I wonder how much of the test here is just carried over mechanically and if we could do something to reduce this churn...
Should be fixed by 39cb2a8fc79976171b20369ff756f7fa43232b50.
Thu, Feb 13
Weird, AffineMinOp and AffineMaxOp do have the trait, they are just below (I asked @OuHangKresnik to add them in one of recent commits). Can we explore more what's the problem with loop.parallel not seing the trait?
Wed, Feb 12
Looks okay for the first take at it.
Can you add a tests where the non-zero offset is exercised?
It looks like similar changes may be needed to mlir-cuda-runner and, potentially, mlir-cpu-runner.
Great work! I only have some nits.
Nit: please explain in the commit message that this was segfaulting before your change, and why it was. Or, as https://mlir.llvm.org/getting_started/DeveloperGuide/ states it, the commit message should explain _why_ you are making the change.
My brain didn't wire up to the simple and new stuff.
Tue, Feb 11
I am mostly nitpicking. Let's finish the design discussion on discourse and land this!
I don't think this belongs to the LLVM dialect. LLVM IR does not have rsqrt as operation or intrinsics, so neither should the dialect. We can have it in a higher-level dialect that lowers to llvm.intr.sqrt (to introduce) and llvm.fdiv (already available). But this expansion should _not_ happen when converting from the LLVM dialect to LLVM IR, that mapping is intentionally kept trivial.
The granularity of exposing them is not clear to me. I also thought about an intrinsics/non-intrinsics split. But even the definition of what intrinsic based lowering means is vague. LLVM::ExpOp is an operation but ultimately lowered to some intrinsic.
Thanks for pushing on this. Having alignment attribute as an ODS argument looks like it would remove a bunch of boilerplate for you.
This would work for me. At scale, we may need to analyze effects of such approach on compile time. The converter essentially twice the number of patterns it has to search through, and there are potential rollbacks of rewrites that generated illegal operations.
Mon, Feb 10
Thanks, Tobias! Let me know if you need me to land this for you.
Layering-wise, this makes sense to me. EDSC is a utility library, similar to IR, and should not depend on an ever-growing set of dialects, rather the inverse.
cmake seems broken
Added example with unranked memref to the doc.
Added a helper view class.
Fri, Feb 7
addressed most comments
I'm missing some higher-level documentation on what each function is supposed to do.
Thu, Feb 6
Wed, Feb 5
Tue, Feb 4
Thanks River, this is very useful!
Almost there, a couple more comments.
LGTM after one nit is fixed.
Mon, Feb 3
I suppose you want high-level feedback on this, so I'm not nitpicking in the code.
I'm wondering how it will be possible to extend the list of patterns for non-standard ops and still make use of the existing LLVMLoweringPass? I'm currently using the patternListFiller to add my own patterns to the pass. If the LLVMLoweringPass was exposed in a header, I could at least reuse that.
Just wondering how this will impact the LLVM lowering customization scalability problem in general. By removing the hook for patterns, won't we go from an explosion of populate* functions to an explosion of LLVM lowering passes?
Thanks! I have a couple of comments inline. Major comments:
- the lowering looks incorrect;
- please call SomethingOp only the thing that is an actual Op in the IR, use OpBase or Base for common implementation details.
Fri, Jan 31
AFAIK, MLIR changes cannot affect libc++ tests so it's okay to land if those are the only problem.
Alex, Thanks for this! It will definitely make things simpler! However, it's going to conflict with D72802. Could we wait for that diff to land and see what else is needed here to keep everything?