[TIR][Transform] Optional data-flow analysis in RemoveNoOp

[Lunderberg]

Previously, RemoveNoOp would remove statements that could be locally analyzed as having no effect (e.g. For with empty loop extents). This commit adds opt-in use of data-flow analysis to identify two types of statements that are no-ops based on their context:

• Buffer stores that are overwritten without ever being read.

  buf[i] = 5 # Overwritten by next statement
  buf[i] = 10

• Storing a value that is already known to be present.

  buf[0:16] = T.ramp(0, 16, 1)
  buf[5] = 5 # Previous load already stored this value

[tvm-bot]

Thanks for contributing to TVM! Please refer to the contributing guidelines https://tvm.apache.org/docs/contribute/ for useful information and tips. Please request code reviews from Reviewers by @-ing them in a comment.

• cc @Hzfengsy, @junrushao _{See #10317 for details}
• Built docs for commit 2662d92 can be found here.

_{Generated by tvm-bot}

[Lunderberg]

This PR is currently a draft, as its branch includes #13130. To maintain independent commits, this will be rebased onto main later.

[Lunderberg]

@tvm-bot rerun

[masahi]

@tvm-bot rerun

[Lunderberg]

Looks like it's currently a compile-time failure, though I'm not sure why. I found a missing #include <algorithm>, which hadn't been caught by include_what_you_use, but I'd expect that to cause other issues if it were the problem. Rebasing onto main in case there were CI-related changes since the previous rebase.

[Lunderberg]

It made it past the compilation stage, so the rebase resolved that issue. Still running into the crash in test_te_schedule_ops.py, due to a double free or corruption. Valgrind complains quite loudly about invalid reads. Other than some caused by the python interpreter's malloc, valgrind is silent when run on main, so it's definitely something triggered by this PR in particular.

[Lunderberg]

Found it!

The std::unordered_map<const VarNode*, Range> var_range_map_ has a non-owning const VarNode*. When this is used for arith::EvalSet, it converts it to an owning Map<Var, Range> using GetRef<Var>(var_ptr). However, there's no guarantee that the Var still exists by that point. If extent is negative, then the loop variable in var_range_map_ is never removed. If there are no other references to the loop variable, then the map will hold a dangling pointer, and the next loop to be examined will have invalid memory access.

Moving the update of var_range_map_ to be after the check for negative extents instead of before avoids these dangling pointers, and passes local valgrind checks.

[masahi]

Very cool feature and interesting test cases!