`HandleVectorExtractPattern` could report `success()` without rewriting
the IR when `llvm.shufflevector` extracted a contiguous slice from a
**block argument** (no defining op). The greedy rewriter’s expensive
checks then aborted with *“pattern returned success but IR did not
change”*.
The pattern only performs work when the shuffle’s operand is defined by
another op (`FPExt`, `FPTrunc`, `bitcast`, nested `shufflevector`, or
`load`). For operands like function arguments, `getDefiningOp()` is
null, so nothing is rewritten; the function still fell through to
`return success()` without changing the IR and would crash when
`MLIR_ENABLE_EXPENSIVE_PATTERN_API_CHECKS` is on. `mlir-opt
--convert-xevm-to-llvm --split-input-file
mlir/test/Conversion/XeVMToLLVM/xevm_mx-to-llvm.mlir` no longer hits the
fatal error.
Assisted-by: Cursor (Composer 2)
f1822ca735