[mlir][Affine] Handle null parent op in getAffineParallelInductionVarOwner #142025
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@llvm/pr-subscribers-mlir-core @llvm/pr-subscribers-mlir-affine Author: Han-Chung Wang (hanhanW) ChangesThis issue is triggered in a downstream project, and it is hard to generate the reproducer and the test. The issue is at this line containingOp is null as the block argument owning ivArg is unlinked if dialect conversion is involved. Co-authored-by: Rahul Kayaith <rkayaith@gmail.com> Full diff: https://github.com/llvm/llvm-project/pull/142025.diff 1 Files Affected:
diff --git a/mlir/lib/Dialect/Affine/IR/AffineOps.cpp b/mlir/lib/Dialect/Affine/IR/AffineOps.cpp
index 2364f8957992d..8a708eb29210c 100644
--- a/mlir/lib/Dialect/Affine/IR/AffineOps.cpp
+++ b/mlir/lib/Dialect/Affine/IR/AffineOps.cpp
@@ -2667,7 +2667,7 @@ AffineParallelOp mlir::affine::getAffineParallelInductionVarOwner(Value val) {
if (!ivArg || !ivArg.getOwner())
return nullptr;
Operation *containingOp = ivArg.getOwner()->getParentOp();
- auto parallelOp = dyn_cast<AffineParallelOp>(containingOp);
+ auto parallelOp = dyn_cast_if_present<AffineParallelOp>(containingOp);
if (parallelOp && llvm::is_contained(parallelOp.getIVs(), val))
return parallelOp;
return nullptr;
|
|
I sympathize that it is hard to provide a repro, but we still need to be able to test behaviors upstream. |
|
Probably a C++ unit test would be the easiest approach here, since you can directly create an unlinked block. Thise seems like a decent example to base the test on: llvm-project/mlir/unittests/IR/IRMapping.cpp Lines 18 to 26 in 572b89a |
I can try, but I'm not sure if I'm able to do it. The other way to think about the change is that it has a safer check for the method. We already check if it is null in the above check, and it is adding an additional check. I don't find direct test for this method in the first commit: 3e497a1 Maybe I can construct a test using c++, but it looks a little over-indexing on testing to me. |
Ah, thanks for the pointer, I'll take a look. My point was that we don't have the bar for all the utilities, and it seems a little weird for this additional check. But yeah, I can try if people think that it is a requirement. |
|
We don't use c++ unit-test in general, but we use test passes. Maybe you can comment a bit more on how you end up in this situation and figure out about the missing upstream coverage and what kind of test-passes would provide the missing coverage for this utility? |
|
The issue occurs during a downstream pass which does dialect conversion, where both module {
func.func @foo(%arg0: memref<100x100xf32>, %arg1: index, %arg2: index, %arg3: index, %arg4: index) -> memref<?x?xf32, strided<[100, 1], offset: ?>> {
%subview = memref.subview %arg0[%arg1, %arg2] [%arg3, %arg4] [1, 1] : memref<100x100xf32> to memref<?x?xf32, strided<[100, 1], offset: ?>>
return %subview : memref<?x?xf32, strided<[100, 1], offset: ?>>
}
}After "builtin.module"() ({
"llvm.func"() <{CConv = #llvm.cconv<ccc>, function_type = !llvm.func<struct<(ptr, ptr, i64, array<2 x i64>, array<2 x i64>)> (ptr, ptr, i64, i64, i64, i64, i64, i64, i64, i64, i64)>, linkage = #llvm.linkage<external>, sym_name = "foo", visibility_ = 0 : i64}> ({
^bb0(%arg0: !llvm.ptr, %arg1: !llvm.ptr, %arg2: i64, %arg3: i64, %arg4: i64, %arg5: i64, %arg6: i64, %arg7: i64, %arg8: i64, %arg9: i64, %arg10: i64):
%0 = "memref.subview"(<<UNKNOWN SSA VALUE>>, <<UNKNOWN SSA VALUE>>, <<UNKNOWN SSA VALUE>>, <<UNKNOWN SSA VALUE>>, <<UNKNOWN SSA VALUE>>) <{operandSegmentSizes = array<i32: 1, 2, 2, 0>, static_offsets = array<i64: -9223372036854775808, -9223372036854775808>, static_sizes = array<i64: -9223372036854775808, -9223372036854775808>, static_strides = array<i64: 1, 1>}> : (memref<100x100xf32>, index, index, index, index) -> memref<?x?xf32, strided<[100, 1], offset: ?>>
"func.return"(%0) : (memref<?x?xf32, strided<[100, 1], offset: ?>>) -> ()
}) : () -> ()
"func.func"() <{function_type = (memref<100x100xf32>, index, index, index, index) -> memref<?x?xf32, strided<[100, 1], offset: ?>>, sym_name = "foo"}> ({
}) : () -> ()
}) {llvm.data_layout = "", llvm.target_triple = ""} : () -> ()The Now |
|
Thanks @rkayaith for the details, I copied it to the PR description and added my own few wordings about why no additinoal test is added. Please take a look, thanks!
|
I'm not concerned about the change itself, it's pretty trivial, but about the upstream test coverage in general. It happens that there are things we can't have coverage for, but it's pretty rare. I don't feel this case falls into this category right now. I can construct a test case as follows: diff --git a/mlir/include/mlir/Dialect/MemRef/TransformOps/MemRefTransformOps.td b/mlir/include/mlir/Dialect/MemRef/TransformOps/MemRefTransformOps.td
index 2d060f3c2da6..f30a57ce38f7 100644
--- a/mlir/include/mlir/Dialect/MemRef/TransformOps/MemRefTransformOps.td
+++ b/mlir/include/mlir/Dialect/MemRef/TransformOps/MemRefTransformOps.td
@@ -84,7 +84,7 @@ def ApplyExpandOpsPatternsOp : Op<Transform_Dialect,
def ApplyExpandStridedMetadataPatternsOp : Op<Transform_Dialect,
"apply_patterns.memref.expand_strided_metadata",
- [DeclareOpInterfaceMethods<PatternDescriptorOpInterface>]> {
+ [DeclareOpInterfaceMethods<ConversionPatternDescriptorOpInterface>]> {
let description = [{
Collects patterns for expanding memref operations that modify the metadata
(sizes, offset, strides) of a memref into easier to analyze constructs.
diff --git a/mlir/lib/Dialect/MemRef/TransformOps/MemRefTransformOps.cpp b/mlir/lib/Dialect/MemRef/TransformOps/MemRefTransformOps.cpp
index 89640ac323b6..2de8d08cdc09 100644
--- a/mlir/lib/Dialect/MemRef/TransformOps/MemRefTransformOps.cpp
+++ b/mlir/lib/Dialect/MemRef/TransformOps/MemRefTransformOps.cpp
@@ -107,7 +107,7 @@ void transform::ApplyExpandOpsPatternsOp::populatePatterns(
}
void transform::ApplyExpandStridedMetadataPatternsOp::populatePatterns(
- RewritePatternSet &patterns) {
+ TypeConverter &typeConverter, RewritePatternSet &patterns) {
memref::populateExpandStridedMetadataPatterns(patterns);
}
diff --git a/mlir/test/Conversion/MemRefToLLVM/memref-subviewfolder-to-llvm.mlir b/mlir/test/Conversion/MemRefToLLVM/memref-subviewfolder-to-llvm.mlir
new file mode 100644
index 000000000000..9dca88fda118
--- /dev/null
+++ b/mlir/test/Conversion/MemRefToLLVM/memref-subviewfolder-to-llvm.mlir
@@ -0,0 +1,26 @@
+// RUN: mlir-opt -transform-interpreter %s | FileCheck %s
+
+module {
+ func.func @foo(%arg0: memref<100x100xf32>, %arg1: index, %arg2: index, %arg3: index, %arg4: index) -> memref<?x?xf32, strided<[100, 1], offset: ?>> {
+ %subview = memref.subview %arg0[%arg1, %arg2] [%arg3, %arg4] [1, 1] : memref<100x100xf32> to memref<?x?xf32, strided<[100, 1], offset: ?>>
+ return %subview : memref<?x?xf32, strided<[100, 1], offset: ?>>
+ }
+}
+
+module attributes {transform.with_named_sequence} {
+ transform.named_sequence @__transform_main(%toplevel_module: !transform.any_op {transform.readonly}) {
+ %func = transform.structured.match ops{["func.func"]} in %toplevel_module
+ : (!transform.any_op) -> !transform.any_op
+ transform.apply_conversion_patterns to %func {
+ transform.apply_conversion_patterns.func.func_to_llvm
+ transform.apply_patterns.memref.expand_strided_metadata
+ } with type_converter {
+ transform.apply_conversion_patterns.memref.memref_to_llvm_type_converter
+ {index_bitwidth = 32, use_opaque_pointers = true}
+ } {
+ legal_dialects = ["llvm"],
+ partial_conversion
+ } : !transform.any_op
+ transform.yield
+ }
+}It's a bit annoying that we can't easily include rewrite patterns through |
hanhanW
added a commit
to iree-org/iree
that referenced
this pull request
May 31, 2025
Carrying revert: - iree-org/llvm-project@1485df6 Cherry-pick: - iree-org/llvm-project@1b7547d (Mirror of llvm/llvm-project#142025) The revision also pathes torch-mlir for getBackwardSlice changes: iree-org/torch-mlir@05a9860 The changes in IREE are for llvm/llvm-project@6a8dde0 Closes #20928 --------- Signed-off-by: hanhanW <hanhan0912@gmail.com>
Signed-off-by: hanhanW <hanhan0912@gmail.com>
|
@joker-eph many thanks for spending your time on this! I'm a little concerned about the change in transform ops because of this simple change. I did not find any use cases in the upstream repo, and I'm afraid that if it'd break other downstream projects. I'm not familiar with the setup, but we'd no longer be able to use it in We also find a comment in TransformInterfaces.td that discourages non-conversion rewrite patterns in the transform op. For transform dialect test, I can follow up on it once we have better setup in upstream. My main goal of the PR is dropping the cherry-pick in our project, so I took a stab at writing the C++ pass. Hopefully, it can address your concern and other contributors can reuse the testing pass in the future, thanks! |
kuhar
approved these changes
Jun 3, 2025
mlir/test/Conversion/MemRefToLLVM/memref-to-llvm-with-transforms.mlir
Outdated
Show resolved
Hide resolved
Signed-off-by: hanhanW <hanhan0912@gmail.com>
|
Thanks for the review. I plan to land the PR tomorrow, just in case if others want to take another look. |
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/138/builds/14086 Here is the relevant piece of the build log for the reference |
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/204/builds/11306 Here is the relevant piece of the build log for the reference |
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/205/builds/11283 Here is the relevant piece of the build log for the reference |
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/203/builds/12493 Here is the relevant piece of the build log for the reference |
|
Hi, is someone looking into this breakage? It appears to be missing a dependency. |
trcrsired
pushed a commit
to trcrsired/llvm-project
that referenced
this pull request
Jun 4, 2025
…ctionVarOwner (llvm#142025)" This reverts commit c3746ff. This breaks build with BUILD_SHARED_LIBS=ON. ``` /usr/bin/ld: CMakeFiles/MLIRTestMemRefToLLVMWithTransforms.dir/TestMemRefToLLVMWithTransforms.cpp.o: in function `(anonymous namespace)::TestMemRefToLLVMWithTransforms::runOnOperation()': TestMemRefToLLVMWithTransforms.cpp:(.text._ZN12_GLOBAL__N_130TestMemRefToLLVMWithTransforms14runOnOperationEv+0x68): undefined reference to `mlir::LowerToLLVMOptions::LowerToLLVMOptions(mlir::MLIRContext*)' /usr/bin/ld: TestMemRefToLLVMWithTransforms.cpp:[ 88%] Built target CodeGenTests (.text._ZN12_GLOBAL__N_130TestMemRefToLLVMWithTransforms14runOnOperationEvmake[2]: Leaving directory '/work2/kparzysz/git/llvm.org/b/x86' +0x80): undefined reference to `mlir::LLVMTypeConverter::LLVMTypeConverter(mlir::MLIRContext*, mlir::LowerToLLVMOptions const&, mlir::DataLayoutAnalysis const*)' /usr/bin/ld: TestMemRefToLLVMWithTransforms.cpp:(.text._ZN12_GLOBAL__N_130TestMemRefToLLVMWithTransforms14runOnOperationEv+0x143): undefined reference to `mlir::populateFuncToLLVMConversionPatterns(mlir::LLVMTypeConverter const&, mlir::RewritePatternSet&, mlir::SymbolTable const*)' /usr/bin/ld: TestMemRefToLLVMWithTransforms.cpp:(.text._ZN12_GLOBAL__N_130TestMemRefToLLVMWithTransforms14runOnOperationEv+0x174): undefined reference to `mlir::LLVMConversionTarget::LLVMConversionTarget(mlir::MLIRContext&)' ```
Sorry about that and thanks for the revert. I'm looking at it and I'll land it with the fix. |
|
I'm confused that why it is not detected by other presubmit cmake build, including my local cmake build. |
You can reproduce the build config we use on the amdgpu buildbots from using the CMake cache file in |
Thanks, I can reproduce it locally, and I will re-land the PR with the fix. |
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/80/builds/13855 Here is the relevant piece of the build log for the reference |
|
again... I verified that the AMDGPU one is happy, I should check all the bots.. I'll revert it. Sorry about that. |
|
oh, I misread the PR status. It is a late notification, but not saying my fix in the other PR is causing the issue. |
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/130/builds/13563 Here is the relevant piece of the build log for the reference |
rorth
pushed a commit
to rorth/llvm-project
that referenced
this pull request
Jun 11, 2025
…Owner (llvm#142025) The issue occurs during a downstream pass which does dialect conversion, where both [`FuncOpConversion`](https://github.com/llvm/llvm-project/blob/cde67b6663f994fcb4ded28fd79b23a13d347c4a/mlir/lib/Conversion/FuncToLLVM/FuncToLLVM.cpp#L480) and [`SubviewFolder`](https://github.com/llvm/llvm-project/blob/cde67b6663f994fcb4ded28fd79b23a13d347c4a/mlir/lib/Dialect/MemRef/Transforms/ExpandStridedMetadata.cpp#L187) are run together. The original starting IR is: ```mlir module { func.func @foo(%arg0: memref<100x100xf32>, %arg1: index, %arg2: index, %arg3: index, %arg4: index) -> memref<?x?xf32, strided<[100, 1], offset: ?>> { %subview = memref.subview %arg0[%arg1, %arg2] [%arg3, %arg4] [1, 1] : memref<100x100xf32> to memref<?x?xf32, strided<[100, 1], offset: ?>> return %subview : memref<?x?xf32, strided<[100, 1], offset: ?>> } } ``` After `FuncOpConversion` runs, the IR looks like: ```mlir "builtin.module"() ({ "llvm.func"() <{CConv = #llvm.cconv<ccc>, function_type = !llvm.func<struct<(ptr, ptr, i64, array<2 x i64>, array<2 x i64>)> (ptr, ptr, i64, i64, i64, i64, i64, i64, i64, i64, i64)>, linkage = #llvm.linkage<external>, sym_name = "foo", visibility_ = 0 : i64}> ({ ^bb0(%arg0: !llvm.ptr, %arg1: !llvm.ptr, %arg2: i64, %arg3: i64, %arg4: i64, %arg5: i64, %arg6: i64, %arg7: i64, %arg8: i64, %arg9: i64, %arg10: i64): %0 = "memref.subview"(<<UNKNOWN SSA VALUE>>, <<UNKNOWN SSA VALUE>>, <<UNKNOWN SSA VALUE>>, <<UNKNOWN SSA VALUE>>, <<UNKNOWN SSA VALUE>>) <{operandSegmentSizes = array<i32: 1, 2, 2, 0>, static_offsets = array<i64: -9223372036854775808, -9223372036854775808>, static_sizes = array<i64: -9223372036854775808, -9223372036854775808>, static_strides = array<i64: 1, 1>}> : (memref<100x100xf32>, index, index, index, index) -> memref<?x?xf32, strided<[100, 1], offset: ?>> "func.return"(%0) : (memref<?x?xf32, strided<[100, 1], offset: ?>>) -> () }) : () -> () "func.func"() <{function_type = (memref<100x100xf32>, index, index, index, index) -> memref<?x?xf32, strided<[100, 1], offset: ?>>, sym_name = "foo"}> ({ }) : () -> () }) {llvm.data_layout = "", llvm.target_triple = ""} : () -> () ``` The `<<UNKNOWN SSA VALUE>>`'s here are block arguments of a separate unlinked block, which is disconnected from the rest of the IR (so not only is the IR verifier-invalid, it can't even be parsed). This IR is created by signature conversion in the dialect conversion infra. Now `SubviewFolder` is applied, and the utility function here is called on one of these disconnected block arguments, causing a crash. The TestMemRefToLLVMWithTransforms pass is introduced to exercise the bug, and it can be reused by other contributors in the future. --------- Signed-off-by: hanhanW <hanhan0912@gmail.com> Co-authored-by: Rahul Kayaith <rkayaith@gmail.com>
rorth
pushed a commit
to rorth/llvm-project
that referenced
this pull request
Jun 11, 2025
…ctionVarOwner (llvm#142025)" This reverts commit c3746ff. This breaks build with BUILD_SHARED_LIBS=ON. ``` /usr/bin/ld: CMakeFiles/MLIRTestMemRefToLLVMWithTransforms.dir/TestMemRefToLLVMWithTransforms.cpp.o: in function `(anonymous namespace)::TestMemRefToLLVMWithTransforms::runOnOperation()': TestMemRefToLLVMWithTransforms.cpp:(.text._ZN12_GLOBAL__N_130TestMemRefToLLVMWithTransforms14runOnOperationEv+0x68): undefined reference to `mlir::LowerToLLVMOptions::LowerToLLVMOptions(mlir::MLIRContext*)' /usr/bin/ld: TestMemRefToLLVMWithTransforms.cpp:[ 88%] Built target CodeGenTests (.text._ZN12_GLOBAL__N_130TestMemRefToLLVMWithTransforms14runOnOperationEvmake[2]: Leaving directory '/work2/kparzysz/git/llvm.org/b/x86' +0x80): undefined reference to `mlir::LLVMTypeConverter::LLVMTypeConverter(mlir::MLIRContext*, mlir::LowerToLLVMOptions const&, mlir::DataLayoutAnalysis const*)' /usr/bin/ld: TestMemRefToLLVMWithTransforms.cpp:(.text._ZN12_GLOBAL__N_130TestMemRefToLLVMWithTransforms14runOnOperationEv+0x143): undefined reference to `mlir::populateFuncToLLVMConversionPatterns(mlir::LLVMTypeConverter const&, mlir::RewritePatternSet&, mlir::SymbolTable const*)' /usr/bin/ld: TestMemRefToLLVMWithTransforms.cpp:(.text._ZN12_GLOBAL__N_130TestMemRefToLLVMWithTransforms14runOnOperationEv+0x174): undefined reference to `mlir::LLVMConversionTarget::LLVMConversionTarget(mlir::MLIRContext&)' ```
DhruvSrivastavaX
pushed a commit
to DhruvSrivastavaX/lldb-for-aix
that referenced
this pull request
Jun 12, 2025
…Owner (llvm#142025) The issue occurs during a downstream pass which does dialect conversion, where both [`FuncOpConversion`](https://github.com/llvm/llvm-project/blob/cde67b6663f994fcb4ded28fd79b23a13d347c4a/mlir/lib/Conversion/FuncToLLVM/FuncToLLVM.cpp#L480) and [`SubviewFolder`](https://github.com/llvm/llvm-project/blob/cde67b6663f994fcb4ded28fd79b23a13d347c4a/mlir/lib/Dialect/MemRef/Transforms/ExpandStridedMetadata.cpp#L187) are run together. The original starting IR is: ```mlir module { func.func @foo(%arg0: memref<100x100xf32>, %arg1: index, %arg2: index, %arg3: index, %arg4: index) -> memref<?x?xf32, strided<[100, 1], offset: ?>> { %subview = memref.subview %arg0[%arg1, %arg2] [%arg3, %arg4] [1, 1] : memref<100x100xf32> to memref<?x?xf32, strided<[100, 1], offset: ?>> return %subview : memref<?x?xf32, strided<[100, 1], offset: ?>> } } ``` After `FuncOpConversion` runs, the IR looks like: ```mlir "builtin.module"() ({ "llvm.func"() <{CConv = #llvm.cconv<ccc>, function_type = !llvm.func<struct<(ptr, ptr, i64, array<2 x i64>, array<2 x i64>)> (ptr, ptr, i64, i64, i64, i64, i64, i64, i64, i64, i64)>, linkage = #llvm.linkage<external>, sym_name = "foo", visibility_ = 0 : i64}> ({ ^bb0(%arg0: !llvm.ptr, %arg1: !llvm.ptr, %arg2: i64, %arg3: i64, %arg4: i64, %arg5: i64, %arg6: i64, %arg7: i64, %arg8: i64, %arg9: i64, %arg10: i64): %0 = "memref.subview"(<<UNKNOWN SSA VALUE>>, <<UNKNOWN SSA VALUE>>, <<UNKNOWN SSA VALUE>>, <<UNKNOWN SSA VALUE>>, <<UNKNOWN SSA VALUE>>) <{operandSegmentSizes = array<i32: 1, 2, 2, 0>, static_offsets = array<i64: -9223372036854775808, -9223372036854775808>, static_sizes = array<i64: -9223372036854775808, -9223372036854775808>, static_strides = array<i64: 1, 1>}> : (memref<100x100xf32>, index, index, index, index) -> memref<?x?xf32, strided<[100, 1], offset: ?>> "func.return"(%0) : (memref<?x?xf32, strided<[100, 1], offset: ?>>) -> () }) : () -> () "func.func"() <{function_type = (memref<100x100xf32>, index, index, index, index) -> memref<?x?xf32, strided<[100, 1], offset: ?>>, sym_name = "foo"}> ({ }) : () -> () }) {llvm.data_layout = "", llvm.target_triple = ""} : () -> () ``` The `<<UNKNOWN SSA VALUE>>`'s here are block arguments of a separate unlinked block, which is disconnected from the rest of the IR (so not only is the IR verifier-invalid, it can't even be parsed). This IR is created by signature conversion in the dialect conversion infra. Now `SubviewFolder` is applied, and the utility function here is called on one of these disconnected block arguments, causing a crash. The TestMemRefToLLVMWithTransforms pass is introduced to exercise the bug, and it can be reused by other contributors in the future. --------- Signed-off-by: hanhanW <hanhan0912@gmail.com> Co-authored-by: Rahul Kayaith <rkayaith@gmail.com>
DhruvSrivastavaX
pushed a commit
to DhruvSrivastavaX/lldb-for-aix
that referenced
this pull request
Jun 12, 2025
…ctionVarOwner (llvm#142025)" This reverts commit c3746ff. This breaks build with BUILD_SHARED_LIBS=ON. ``` /usr/bin/ld: CMakeFiles/MLIRTestMemRefToLLVMWithTransforms.dir/TestMemRefToLLVMWithTransforms.cpp.o: in function `(anonymous namespace)::TestMemRefToLLVMWithTransforms::runOnOperation()': TestMemRefToLLVMWithTransforms.cpp:(.text._ZN12_GLOBAL__N_130TestMemRefToLLVMWithTransforms14runOnOperationEv+0x68): undefined reference to `mlir::LowerToLLVMOptions::LowerToLLVMOptions(mlir::MLIRContext*)' /usr/bin/ld: TestMemRefToLLVMWithTransforms.cpp:[ 88%] Built target CodeGenTests (.text._ZN12_GLOBAL__N_130TestMemRefToLLVMWithTransforms14runOnOperationEvmake[2]: Leaving directory '/work2/kparzysz/git/llvm.org/b/x86' +0x80): undefined reference to `mlir::LLVMTypeConverter::LLVMTypeConverter(mlir::MLIRContext*, mlir::LowerToLLVMOptions const&, mlir::DataLayoutAnalysis const*)' /usr/bin/ld: TestMemRefToLLVMWithTransforms.cpp:(.text._ZN12_GLOBAL__N_130TestMemRefToLLVMWithTransforms14runOnOperationEv+0x143): undefined reference to `mlir::populateFuncToLLVMConversionPatterns(mlir::LLVMTypeConverter const&, mlir::RewritePatternSet&, mlir::SymbolTable const*)' /usr/bin/ld: TestMemRefToLLVMWithTransforms.cpp:(.text._ZN12_GLOBAL__N_130TestMemRefToLLVMWithTransforms14runOnOperationEv+0x174): undefined reference to `mlir::LLVMConversionTarget::LLVMConversionTarget(mlir::MLIRContext&)' ```
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The issue occurs during a downstream pass which does dialect conversion, where both
FuncOpConversionandSubviewFolderare run together. The original starting IR is:After
FuncOpConversionruns, the IR looks like:The
<<UNKNOWN SSA VALUE>>'s here are block arguments of a separate unlinked block, which is disconnected from the rest of the IR (so not only is the IR verifier-invalid, it can't even be parsed). This IR is created by signature conversion in the dialect conversion infra.Now
SubviewFolderis applied, and the utility function here is called on one of these disconnected block arguments, causing a crash.The TestMemRefToLLVMWithTransforms pass is introduced to exercise the bug, and it can be reused by other contributors in the future.
Co-authored-by: Rahul Kayaith rkayaith@gmail.com