llvm-project

8a3e7cdc - [MLIR][XeVM] Fix mask lifetime in HandleVectorExtractPattern (#223879)

[MLIR][XeVM] Fix mask lifetime in HandleVectorExtractPattern (#223879) When a contiguous-slice shuffle is hoisted through a bitcast that changes the element count, the slice is rewritten against the bitcast source by rescaling the mask into a local SmallVector and rebinding the `mask` ArrayRef to it. That SmallVector was declared inside the `if (maskScale != 1)` block, so it was destroyed before the two uses of `mask` that follow the block - a stack-use-after-scope. It is benign on uninstrumented builds, which is why precommit did not catch it, but the sanitizer bots trap it on Conversion/XeVMToLLVM/mxfp_scale_binary_hoist.mlir, the first test whose chain drives the length-changing bitcast path: ERROR: AddressSanitizer: stack-use-after-scope READ of size 4 #23 mlir::detail::DenseArrayAttrImpl<int>::get(MLIRContext*, ArrayRef<int>) #24 mlir::LLVM::ShuffleVectorOp::build(..., ArrayRef<int>) #26 HandleVectorExtractPattern::matchAndRewrite XeVMToLLVM.cpp:1866:27 Address is located in stack of thread T0 at offset 304 in frame #0 HandleVectorExtractPattern::matchAndRewrite XeVMToLLVM.cpp:1801 [288, 352) 'newMask' (line 1856) <== Memory access at offset 304 is inside this variable SUMMARY: AddressSanitizer: stack-use-after-scope ASan reports the above, MSan reports a read of uninitialized memory and HWASan a tag mismatch. In each case mlir-opt dies partway through --split-input-file, so the surface symptom is the CHECK-LABEL of the second module in that file not being found: https://lab.llvm.org/buildbot/#/builders/52/builds/20099 https://lab.llvm.org/buildbot/#/builders/164/builds/25415 https://lab.llvm.org/buildbot/#/builders/169/builds/26571 https://lab.llvm.org/buildbot/#/builders/55/builds/33165 Hoist the declaration so it outlives the uses, and add a lit test for the length-changing bitcast path, which previously had no direct coverage - the existing tests only bitcast between equal element counts.