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

Denis Antrushin via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Aug 4 11:22:21 PDT 2020


dantrushin added a comment.

F12488999: peephole.mir <https://reviews.llvm.org/F12488999>
Attached test will explode if `isTied` check is removed as suggested. 
Essential part is:

  %10:gr64 = MOV64rm killed %9, 1, $noreg, 0, $noreg :: (load 8 from %ir.p0, addrspace 1)
  %6:gr64, %7:gr64 = STATEPOINT 0, 0, 0, @foo, 2, 0, 2, 0, 2, 0, %8, %8(tied-def 0), killed %10, %0(tied-def 1), ...

It is synthetic (i.e. we do no generate such MIR from any IR), but still not invalid



================
Comment at: llvm/lib/CodeGen/TargetInstrInfo.cpp:506
+      return nullptr;
+    // When called from regalloc (InlineSpiller), operands must be untied,
+    // and regalloc will take care of (re)loading operand from memory.
----------------
reames wrote:
> I don't believe this line or comment are necessary.  Please remove if make check passes; if not, I will handle in follow up.
> 
> optimizeMemoryInst (the peephole entry point) rejects all defs, not just tied defs.
> I don't believe this line or comment are necessary.  Please remove if make check passes; if not, I will handle in follow up.
> 
> optimizeMemoryInst (the peephole entry point) rejects all defs, not just tied defs.

The possible path is:

PeepholeOptimizer::runOnMachineFunction (!isLoadFoldable() branch) ->
X86InstrInfo::optimizeLoadInstr ->
TargetInstrInfo::foldMemoryOperand ->
TargetInstrInfo::foldPatchpoint (here)

The fact this path is not exercised now is implementation detail (it did with earlier versions of ISEL patch).
I think we should keep this check to stay on the safe side.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81646



More information about the llvm-commits mailing list