Replace math::LogOp with an approximations from the the Julien Pommier's SSE math library
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Event Timeline
mlir/lib/Dialect/Math/Transforms/PolynomialApproximation.cpp | ||
---|---|---|
96 | I'm not sure it is a great thing to "re-invent" a new custom builder for the sake of a single pass: I'd like River/Alex to have another look. | |
326 | Can we document the polynomial expansion? Or link to a documentation? (I don't find it on this link, I just found the raw source code). |
mlir/lib/Dialect/Math/Transforms/PolynomialApproximation.cpp | ||
---|---|---|
96 | The goal here is to create concise API that looks and feels like Eigen (approximations will come from Eigen initially). It is a ton of complexity in approximations itself, so it is nice to hide builders boilerplate and focus on numerics. |
mlir/lib/Dialect/Math/Transforms/PolynomialApproximation.cpp | ||
---|---|---|
96 | I sympathize, but I favor consistency in the MLIR project in itself in general. And having different ad-hoc builders or custom eDSLs that become pass specific is going against it. |
mlir/lib/Dialect/Math/Transforms/PolynomialApproximation.cpp | ||
---|---|---|
96 | I'm also a big fan of consistency :) In this case I think that's petty much the final state of this DSL, because all approximations are built from add/mul/cast/shift, and that's it. Also Rasmus is working on improving approximations in Eigen, and because he is the only expert I know of we have around, I hope to lure him into contributing to MLIR, and want to make this process as frictionless as possible. |
mlir/lib/Dialect/Math/Transforms/PolynomialApproximation.cpp | ||
---|---|---|
96 | Thanks Eugene for starting this, definitely better place to upstream some of IREE's fast math (e.g: https://github.com/google/iree/blob/main/iree/compiler/Conversion/LLVMToLLVM/FastExpConversion.cpp) . Regarding Mehdi's custom builder point and looking at the log-approximation, Did you consider just using EDSC builders for each approximation ? llvm_madd, llvm_select...etc EDSC intrinsics that can be used and hides the builder and looks like the current API/DSL. |
mlir/lib/Dialect/Math/Transforms/PolynomialApproximation.cpp | ||
---|---|---|
96 | I would say that some of the helpers seem useful, e.g. the ones that create a complex chain of operations. On the other hand, all of the methods that are one-to-one mappings do not really provide any value IMO. I don't think we should be creating these kinds of APIs. I would also prefer that we do not let EDSCs creep in here. |
mlir/lib/Dialect/Math/Transforms/PolynomialApproximation.cpp | ||
---|---|---|
96 |
EDSC is somehow in the same category, and kind of deprecated upstream at this point. |
mlir/lib/Dialect/Math/Transforms/PolynomialApproximation.cpp | ||
---|---|---|
96 | I've implemented this patch using builder API in https://reviews.llvm.org/D97304, IMHO it is much harder to grasp what's going on behind all the builder/rewriter boilerplate, approximations themself are kind of ok, but frexp implementation for example is just lost in all these .create<....>(loc, ... over and over. |
mlir/lib/Dialect/Math/Transforms/PolynomialApproximation.cpp | ||
---|---|---|
96 | Using something like > would remove all of the loc, : https://github.com/llvm/llvm-project/blob/18b9fc48f1b64061699533740dd6218c982f5b58/mlir/include/mlir/IR/ImplicitLocOpBuilder.h#L23 |
mlir/lib/Dialect/Math/Transforms/PolynomialApproximation.cpp | ||
---|---|---|
96 | I'd really like for us to have builders that are making the code easier to read, it has been hard to make progress on this in the past, but more feedback and example can help. Would you mind providing feedback (and point to this revision) here: https://llvm.discourse.group/t/rfc-dsl-style-dialect-specific-builders/1823 ? |
mlir/lib/Dialect/Math/Transforms/PolynomialApproximation.cpp | ||
---|---|---|
96 | I've did another round with ImplicitLocOpBuilder and small number of helper functions, and now it looks reasonably good: https://reviews.llvm.org/D97304 |
I'm not sure it is a great thing to "re-invent" a new custom builder for the sake of a single pass: I'd like River/Alex to have another look.