LGTM after changing the test to capture %arg0 and %arg1. Thanks!
Jan 31 2020
This is a summary of the pending items that I would suggest addressing separately:
Jan 30 2020
Split "from" and "to" conversion generation and added more doc as requested.
This is a follow-up to that.
What happens when you have non-parallel loops in the generic op? Can we have a test for this case (even if there's no transform happening, just make sure we bail out instead of generating incorrectly parallel loop?)
Looks good in general, please follow @rriddle's recommendation.
Please LMK if you need somebody to commit this for you
Good catch, thanks!
D71961 is going in the direction of generalizing std.return ; what is the guideline for adding a new op vs re-using std.return?
Jan 29 2020
I'm fine with this, but please make sure @rriddle has no objections either.
One more nit, thanks!
@ftynse it seems approppriate for you to review parts you haven't touched yet though.
I think your review would still be very valuable for sections 3 - 8 (Core Guiding Principles - end).
This looks good to me. I don't fully understand the problem @rriddle mentioned with replaceUsesOfWith, and I wonder if we could have a solution that also avoids the need for the placeholder operation.
I meant that instead of having both I32EnumAttrCase (taking two parameters) and I32StrEnumAttrCase (taking three parameters), what about just having I32EnumAttrCase and making it taking in string cSym, int cVal, string strVal = cSym? Similarly for other *EnumAttrCases.
Use default value for parameter and drop IntStr*
I don't feel it's appropriate for me to review this since I wrote some parts of the text.
Jan 28 2020
Jan 27 2020
Could you plz rebase on master? It does not seem to apply anymore. And fix clang-format while you are there.
Please note that we tend to prefix the header of the commit message with [mlir] so that people on llvm-commits@ can understand the changes are restricted to MLIR (many more people might have a say if actual LLVM IR intrinsics were broken)
Please update the commit message from "fixed tanh lowering" to "add tanh lowering". It was not broken (which would mandate a fix), it was never implemented to start with. Good to go otherwise.
I suppose that, in general, there is no strict correspondance between the number of type suffixes in an overloaded intrinsic and the number of operands. So having one type may make sense for fmuladd, but may not make sense for some platform-specific vector select-like intrinsic with three arguments that would require two types. I would suggest renaming BinaryIntrinsicOp to BinarySameArgsIntrinsicOp if you do this change. Or even dropping it entirely and keeping an explicit definition for copysign and fmuladd since I don't see any other users of the Binary and TernaryIntrinsicOp classes.
Thanks! I have a couple of comments.
Looks generally okay to me. I don't see the point of cloning before erasing, but can live with it pending a clean-up.
Anything else @nicolasvasilache ?
Thanks Alex for adding this! Have you considered adding an additional parameter (defaulting to C++ enumerant symbol) for the string representation instead of duplicating all the cases?
Jan 24 2020
Thanks, I like the simplification.
The change looks innocuous, I would have landed on approval, too.
Jan 23 2020
I'm supportive of this change as long as Mehdi's and River's concerns are addressed.
Looks good in general, I am suggesting to push it one step further.
I reverted this change since it broke dependent projects, and the modeling generally looks incorrect.
Jan 22 2020
Jan 20 2020
Minor comments only.
Jan 17 2020
@tra, your rule adds you as blocking on all of MLIR :)
The change is mostly renaming/clean-up. I only have minor comments, feel free to land after addressing.
To clarify further, LLVM dialect in MLIR is not a new IR, it's essentially a representation of LLVM IR using MLIR. It's supposed to minimize the cost of translation from MLIR to LLVM IR. While it does diverge from LLVM IR proper, it does so for modeling reasons: there's no first-class constants in MLIR, neither are there phi nodes. Changing the name of an enumerand locally to the LLVM dialect will increase the cost of translation, which goes against the goal of this dialect. That being said, I do agree that we should use this opportunity to reflect on LLVM IR design and update it following the proper process.
Changing LLVM IR should _not_ be in this commit, it's semantically different and requires separate discussion with relevant people involved. I also don't see a compelling reason to block this from landing until LLVM IR changes (or decides not to). LLVM dialect models LLVM IR in its current state, whatever the state is.