[all-commits] [llvm/llvm-project] 5dcf82: [MLIR] Fix use-after-move for DEBUG builds, and br...

[Slava Gurevich via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 5dcf82d3da1ff449ca3b19aed56a76112ae6c735
      https://github.com/llvm/llvm-project/commit/5dcf82d3da1ff449ca3b19aed56a76112ae6c735
  Author: Slava Gurevich <sgurevich at gmail.com>
  Date:   2025-10-25 (Sat, 25 Oct 2025)

  Changed paths:
    M mlir/include/mlir/Dialect/SparseTensor/IR/SparseTensor.h
    M mlir/lib/Dialect/SparseTensor/Transforms/Utils/IterationGraphSorter.cpp

  Log Message:
  -----------
  [MLIR] Fix use-after-move for DEBUG builds, and broken assert logic. (#164763)

These issues affect only Debug builds, and Release builds with asserts
enabled.

1. In `SparseTensor.h` a variable is moved-from within an assert,
introducing a side effect that alters its subsequent use, and causes
divergence between Debug and Release builds (with asserts disabled).

2. In `IterationGraphSorter.cpp`, the class constructor arguments are
moved-from to initialize class member variables via the initializer
list. Because both the arguments and class members are identically
named, there's a naming collision where the arguments shadow their
identically-named member variables counterparts inside the constructor
body. In the original code, unqualified names inside the asserts,
referred to the constructor arguments. This is wrong, because these have
already been moved-from. It's not just a UB, but is broken. These
SmallVector types when moved-from are reset i.e. the size resets to 0.
This actually renders the affected asserts ineffective, since the
comparisons operate on two hollowed-out objects and always succeed. This
name ambiguity is fixed by using 'this->' to correctly refer to the
initialized member variables carrying the relevant state.

3. While the fix 2 above made the asserts act as intended, it also
unexpectedly broke one mlir test: `llvm-lit -v
mlir/test/Dialect/SparseTensor/sparse_scalars.mlir` This required fixing
the assert logic itself, which likely has never worked and went
unnoticed all this time due to the bug 2. Specifically, in the failing
test that uses `mlir/test/Dialect/SparseTensor/sparse_scalars.mlir` the
'%argq' of 'ins' is defined as 'f32' scalar type, but the original code
inside the assert had no support for scalar types as written, and was
breaking the test.

Testing:
```
ninja check-mlir
llvm-lit -v mlir/test/Dialect/SparseTensor/sparse_scalars.mlir
```



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications