[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