-
Notifications
You must be signed in to change notification settings - Fork 13.5k
[mlir][Transforms] Support 1:N mappings in ConversionValueMapping
#116524
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[mlir][Transforms] Support 1:N mappings in ConversionValueMapping
#116524
Conversation
16e58e7
to
f027116
Compare
✅ With the latest revision this PR passed the C/C++ code formatter. |
f027116
to
2f3f0ae
Compare
ef8d04d
to
3930f40
Compare
3930f40
to
ce53d95
Compare
ce53d95
to
0bbad0b
Compare
0bbad0b
to
e3946a5
Compare
fe68c3c
to
1511e50
Compare
e3946a5
to
f983e30
Compare
98214ce
to
0e985da
Compare
f9e8758
to
ddc9294
Compare
eff9c47
to
bc93c78
Compare
ddc9294
to
6041464
Compare
bc93c78
to
53f97f5
Compare
…se (#121271) This commit adds a test case that performs two back-to-back 1:N replacements: `(i16) -> (i16, i16) -> ((i16, i16), (i16, i16))`. For the moment, 3 argument materializations are inserted. In the future (when the conversion value mapping supports 1:N), a single target materialization will be inserted. Addresses a [comment](#116524 (comment)) in #116524.
680692f
to
5b49dce
Compare
ba9e0e6
to
8e9b48a
Compare
8e9b48a
to
d78dfb2
Compare
488d8be
to
209d922
Compare
@@ -1478,34 +1497,12 @@ Value ConversionPatternRewriterImpl::findOrBuildReplacementValue( | |||
} | |||
Value castValue = buildUnresolvedMaterialization( | |||
MaterializationKind::Source, computeInsertPoint(repl), value.getLoc(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feared that this would be the case. I fully agree with all your points, the current approach is probably the best for now.
Could we document some of these constraints somewhere? I feel we are missing comments explaining "why" things are being done the way they are.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/140/builds/13959 Here is the relevant piece of the build log for the reference
|
Fix build errors after #116524. ``` error: call of overloaded ‘TypeRange(ValueVector&)’ is ambiguous ```
Since #116524, an integration test started to become flaky (failure rate ~15%). ``` bin/mlir-opt mlir/test/Integration/Dialect/SparseTensor/CPU/sparse_block_matmul.mlir --sparsifier="enable-arm-sve=true enable-runtime-library=false vl=2 reassociate-fp-reductions=true enable-index-optimizations=true" | mlir-cpu-runner --march=aarch64 --mattr="+sve" -e main -entry-point-result=void -shared-libs=./lib/libmlir_runner_utils.so,./lib/libmlir_c_runner_utils.so | bin/FileCheck mlir/test/Integration/Dialect/SparseTensor/CPU/sparse_block_matmul.mlir # executed command: bin/mlir-opt mlir/test/Integration/Dialect/SparseTensor/CPU/sparse_block_matmul.mlir '--sparsifier=enable-arm-sve=true enable-runtime-library=false vl=2 reassociate-fp-reductions=true enable-index-optimizations=true' # .---command stderr------------ # | mlir/test/Integration/Dialect/SparseTensor/CPU/sparse_block_matmul.mlir:71:10: error: null operand found # | %0 = linalg.generic #trait_mul # | ^ # | mlir/test/Integration/Dialect/SparseTensor/CPU/sparse_block_matmul.mlir:71:10: note: see current operation: %70 = "arith.mulf"(<<NULL VALUE>>, %69) <{fastmath = #arith.fastmath<none>}> : (<<NULL TYPE>>, vector<[2]xf64>) -> vector<[2]xf64> # `----------------------------- # error: command failed with exit status: 1 ``` I traced the issue back to the `DenseMap<ValueVector, ValueVector, ValueVectorMapInfo> mapping;` data structure: previously, some `mapping.erase(foo)` calls were unsuccessful (returning `false`), even though the `mapping` contains `foo` as a key.
…ent test case (#121271) This commit adds a test case that performs two back-to-back 1:N replacements: `(i16) -> (i16, i16) -> ((i16, i16), (i16, i16))`. For the moment, 3 argument materializations are inserted. In the future (when the conversion value mapping supports 1:N), a single target materialization will be inserted. Addresses a [comment](llvm/llvm-project#116524 (comment)) in #116524.
This commit updates the internal
ConversionValueMapping
data structure in the dialect conversion driver to support 1:N replacements. This is the last major commit for adding 1:N support to the dialect conversion driver.Since #116470, the infrastructure already supports 1:N replacements. But the
ConversionValueMapping
still stored 1:1 value mappings. To that end, the driver inserted temporary argument materializations (converting N SSA values into 1 value). This is no longer the case. Argument materializations are now entirely gone. (They will be deleted from the type converter after some time, when we delete the old 1:N dialect conversion driver.)Note for LLVM integration: Replace all occurrences of
addArgumentMaterialization
(except for 1:N dialect conversion passes) withaddSourceMaterialization
.