[PATCH] D81646: MIR Statepoint refactoring. Part 2: Operand folding.

[Philip Reames via Phabricator via llvm-commits]

reames added a comment.

In D81646#2092782 <https://reviews.llvm.org/D81646#2092782>, @dantrushin wrote:

> In D81646#2091262 <https://reviews.llvm.org/D81646#2091262>, @reames wrote:
>
> > I can't wrap my head around why untieing operands would be correct here.  It seems like we could end up with a use folded, but a def not leaving to invalid codegen?  Can you either expand on the justification or discuss offline?
>
>
> The key point here is that we have two-address form at this point (not SSA, i.e. register on both sides is the same: vreg1 = STATEPOINT vreg1<tied-def0>).
>  `foldMemoryOperand` is called from `spillAroundUses` in InlineSpiller. And this method (besides few other optimizations) for every VReg use tries to fold register into memory operand or, if unsuccessful, inserts reload before instruction.
>  In some sense it turns VReg into StackSlot. And since Def of stack slot is invisible to LLVM (just like with old statepoint), it "magically" works.


But you're converting an instruction which defines a vreg to one which doesn't.  If the original definition vreg had uses, isn't this a miscompile?

vreg1 = statepoint .... vreg1 (tied)
vreg2 = ADDri vreg1, 20

>
=

statepoint ... [FI]
vreg2 = ADDri vreg1, 20  <-- What's the value of vreg1 here?

We could insert a fill after the folded statepoint, but I don't see code which does that?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D81646/new/

https://reviews.llvm.org/D81646