[llvm] [CodeGenPrepare] Handle address sinking obtained from invoke (PR #143566)
via llvm-commits
llvm-commits at lists.llvm.org
Wed Jun 11 15:00:48 PDT 2025
================
@@ -5790,7 +5790,8 @@ static BasicBlock::iterator findInsertPos(Value *Addr, Instruction *MemoryInst,
// instruction after it.
if (SunkAddr) {
if (Instruction *AddrInst = dyn_cast<Instruction>(SunkAddr))
- return std::next(AddrInst->getIterator());
+ return AddrInst->isTerminator() ? MemoryInst->getIterator()
+ : std::next(AddrInst->getIterator());
----------------
weiguozhi wrote:
The purpose of optimizeMemoryInst is to find address computation in PrevBB, and the address is used in a memory access instruction in a SuccBB, it then duplicate the address computation in SuccBB, SelectionDAG can fold the address computation into memory access.
> > We should make sure ResultPtr is in current BB before directly using it as SunkAddr.
>
> We use global pointers safely because we can't get iterator in a BB for them. Do we want to handle them similarly to instructions in other blocks?
Global pointers is absolutely OK in a memory access instruction, but it doesn't fit into this optimization.
>
> > If ResultPtr is not in current BB we can clone it as the SunkAddr in current BB.
>
> Clone -- do you mean create GEP with 0?
Duplicate the address computation instruction. (thus SunkAddr)
>
> > Invoke instruction is not a good candidate for SunkAddr.
>
> Not obvious to me, why is it different from instructions in other blocks or from globals?
We can't fold Invoke instruction into a memory access instruction.
https://github.com/llvm/llvm-project/pull/143566
More information about the llvm-commits
mailing list