[all-commits] [llvm/llvm-project] 31342e: [Statepoint] When using the tied def lowering, unc...

Philip Reames via All-commits all-commits at lists.llvm.org
Wed Jul 29 09:24:12 PDT 2020


  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 31342eb63e93ae1f453fe61924bd2c1f134dd1c0
      https://github.com/llvm/llvm-project/commit/31342eb63e93ae1f453fe61924bd2c1f134dd1c0
  Author: Philip Reames <listmail at philipreames.com>
  Date:   2020-07-29 (Wed, 29 Jul 2020)

  Changed paths:
    M llvm/lib/CodeGen/SelectionDAG/StatepointLowering.cpp
    M llvm/lib/CodeGen/SelectionDAG/StatepointLowering.h
    M llvm/test/CodeGen/X86/statepoint-vreg.ll

  Log Message:
  -----------
  [Statepoint] When using the tied def lowering, unconditionally use vregs [almost NFC]

This builds on 3da1a96 on the path towards supporting invokes and cross block relocations. The actual change attempts to be NFC, but does fail in one corner-case explained below.

The change itself is fairly mechanical. Rather than remember SDValues - which are inherently block local - immediately produce a virtual register copy and remember that.

Once this lands, we'll update the FunctionLoweringInfo::StatepointSpillMap map to allow register based lowerings, delete VirtRegs from StatepointLowering, and drop the restriction against cross block relocations. I deliberately separate the semantic part into it's own change for easy of understanding and fault isolation.

The corner-case which isn't quite NFC is that the old implementation implicitly CSEd gc.relocates of the same SDValue regardless of type. The new implementation still only relocates once, but it produces distinct vregs for the bitcast and it's source, whereas SelectionDAG's generic CSE was able to remove the bitcast in the old implementation. Note that the final assembly doesn't change (at least in the test), as our MI level optimizations catch the duplication.

I assert that this is an uninteresting corner-case. It's functionally correct, and if we find a case where this influences performance, we should really be canonicalizing types to i8* at the IR level.

Differential Revision: https://reviews.llvm.org/D84692




More information about the All-commits mailing list