[llvm] [Inliner] Fix assertion failure in BlockAddress::get during inlining (PR #176044)

[Aiden Grossman via llvm-commits]

================
@@ -0,0 +1,23 @@
+; RUN: opt -S -passes=always-inline %s | FileCheck %s
+
+; Ensure that a function with a blockaddress usage is NOT inlined.
----------------
boomanaiden154 wrote:

Getting a stack trace from `lld`, it looks like the original assertion occurred in the IR Mover at IR link time since the original issue used LTO. Relevant parts of the stack trace:

```
#10 0x000055b20f20ea18 llvm::BlockAddress::get(llvm::Function*, llvm::BasicBlock*) /home/gha/llvm-project/llvm/lib/IR/Constants.cpp:1933:14
#11 0x000055b20e3a2bef (anonymous namespace)::Mapper::mapBlockAddress(llvm::BlockAddress const&) /home/gha/llvm-project/llvm/lib/Transforms/Utils/ValueMapper.cpp:608:25
#12 0x000055b20e39ecfd (anonymous namespace)::Mapper::mapValue(llvm::Value const*) /home/gha/llvm-project/llvm/lib/Transforms/Utils/ValueMapper.cpp:443:5
#13 0x000055b20e39fa5f (anonymous namespace)::Mapper::remapInstruction(llvm::Instruction*) /home/gha/llvm-project/llvm/lib/Transforms/Utils/ValueMapper.cpp:982:12
#14 0x000055b20e3a097c (anonymous namespace)::Mapper::remapFunction(llvm::Function&) /home/gha/llvm-project/llvm/lib/Transforms/Utils/ValueMapper.cpp:1092:28
#15 0x000055b20e3a23a0 (anonymous namespace)::Mapper::flush() /home/gha/llvm-project/llvm/lib/Transforms/Utils/ValueMapper.cpp:931:3
#16 0x000055b20e39e3c8 (anonymous namespace)::FlushingMapper::~FlushingMapper() /home/gha/llvm-project/llvm/lib/Transforms/Utils/ValueMapper.cpp:1221:34
#17 0x000055b20e39e412 llvm::ValueMapper::mapValue(llvm::Value const&) /home/gha/llvm-project/llvm/lib/Transforms/Utils/ValueMapper.cpp:1247:3
#18 0x000055b20da6f5e0 (anonymous namespace)::IRLinker::run() /home/gha/llvm-project/llvm/lib/Linker/IRMover.cpp:1528:12
#19 0x000055b20da6e93b llvm::IRMover::move(std::unique_ptr<llvm::Module, std::default_delete<llvm::Module>>, llvm::ArrayRef<llvm::GlobalValue*>, llvm::unique_function<void (llvm::GlobalValue&, std::function<void (llvm::GlobalValue&)>)>, bool) /home/gha/llvm-project/llvm/lib/Linker/IRMover.cpp:1696:1
#20 0x000055b20bd00809 llvm::lto::LTO::linkRegularLTO(llvm::lto::LTO::RegularLTOState::AddedModule, bool) /home/gha/llvm-project/llvm/lib/LTO/LTO.cpp:1085:3
#21 0x000055b20bd016e5 llvm::lto::LTO::runRegularLTO(std::function<llvm::Expected<std::unique_ptr<llvm::CachedFileStream, std::default_delete<llvm::CachedFileStream>>> (unsigned int, llvm::Twine const&)>) /home/gha/llvm-project/llvm/lib/LTO/LTO.cpp:1297:23
#22 0x000055b20bd011ab llvm::lto::LTO::run(std::function<llvm::Expected<std::unique_ptr<llvm::CachedFileStream, std::default_delete<llvm::CachedFileStream>>> (unsigned int, llvm::Twine const&)>, llvm::FileCache) /home/gha/llvm-project/llvm/lib/LTO/LTO.cpp:1268:18
#23 0x000055b208b6d720 lld::elf::BitcodeCompiler::compile() /home/gha/llvm-project/lld/ELF/LTO.cpp:338:31
```

So it seems like the actual issue has nothing to do with inlining. This test case also does not crash for me locally at current tip of tree.

We should probably make the inliner change regardless given the `callbr` block address changes, but that should be NFC.



https://github.com/llvm/llvm-project/pull/176044