[all-commits] [llvm/llvm-project] ae6a5c: llvm-reduce: Fix assertion on blockaddress during ...

[Matt Arsenault via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: ae6a5c1d08d8ac251a2b3dc08b023126b21b1b53
      https://github.com/llvm/llvm-project/commit/ae6a5c1d08d8ac251a2b3dc08b023126b21b1b53
  Author: Matt Arsenault <Matthew.Arsenault at amd.com>
  Date:   2023-01-11 (Wed, 11 Jan 2023)

  Changed paths:
    A llvm/test/tools/llvm-reduce/reduce-functions-blockaddress-wrong-function.ll
    A llvm/test/tools/llvm-reduce/reduce-functions-blockaddress.ll
    M llvm/tools/llvm-reduce/deltas/ReduceFunctions.cpp
    M llvm/tools/llvm-reduce/deltas/Utils.cpp
    M llvm/tools/llvm-reduce/deltas/Utils.h

  Log Message:
  -----------
  llvm-reduce: Fix assertion on blockaddress during function reduction

Just avoid crashing for now, we should be able to replace the blockaddresses
themselves.

BlockAddress::handleOperandChangeImpl assumes it can cast to Function.
The verifier seems nonexistent and the langref isn't particularly explicit
on what's allowed as a blockaddress operand. As far as I can tell bugpoint
isn't doing anything to handle this.

Something low level is broken with BlockAddress handling,
demonstrated by reduce-functions-blockaddress-wrong-function.ll.
The BasicBlock destructor of the deleted function is triggering replacement
of blockaddresses for the kept function in some cases. I've only half debugged
this but it seems like blockaddress is handled too-specially compared to other
Constants. I have tentative patches to allow any constant to be a blockaddress
input, but having the verifier check if it's really a function/block.

https://reviews.llvm.org/D140909