PATCHES: R600/SI: Remove M0Reg register class

Tom Stellard tom at stellard.net
Mon May 4 09:26:27 PDT 2015


On Mon, May 04, 2015 at 08:55:34AM -0700, Matt Arsenault wrote:
> On 05/04/2015 07:53 AM, Tom Stellard wrote:
> >Hi,
> >
> >These patches remove the M0Reg register class from the R600/SI backend.
> >This was a register class with a single register (m0), and it what used to
> >model implicit usage of m0.
> >
> >In order to remove this register class, I have replaced all explicit m0 uses
> >with implicit uses.  This was achieved by glueing SDNodes with implicit
> >m0 uses to SDNodes which copied values into m0.  The MachineCSE pass
> >takes care of eliminating unnecessary copies so code quality is on par with what
> >was generated before.
> >
> >The benefit of removing this class is that we no longer have to deal with m0 register
> >spills, which were often unnecessary and we can remove special handling for the M0Reg
> >class from a few places in the backend.
> >
> >-Tom
> >
> >0001-MachineCSE-Add-a-target-query-for-the-LookAheadLimit.patch
> >
> >
> > From 6e5f3464ed07a3e36aa99167e73089377af7ad91 Mon Sep 17 00:00:00 2001
> >From: Tom Stellard<thomas.stellard at amd.com>
> >Date: Tue, 28 Apr 2015 12:41:39 +0000
> >Subject: [PATCH 1/8] MachineCSE: Add a target query for the LookAheadLimit
> >  heurisitic
> >
> >This is used to determine whether or not to CSE physical register
> >defs.
> >---
> >  include/llvm/Target/TargetInstrInfo.h | 8 ++++++++
> >  lib/CodeGen/MachineCSE.cpp            | 5 +++--
> >  lib/Target/R600/SIInstrInfo.h         | 2 ++
> >  3 files changed, 13 insertions(+), 2 deletions(-)
> >
> >diff --git a/include/llvm/Target/TargetInstrInfo.h b/include/llvm/Target/TargetInstrInfo.h
> >index f9c1e52..7d95454 100644
> >--- a/include/llvm/Target/TargetInstrInfo.h
> >+++ b/include/llvm/Target/TargetInstrInfo.h
> >@@ -1235,6 +1235,14 @@ public:
> >      return false;
> >    }
> >+  /// \brief Return the value to use for the MachineCSE's LookAheadLimit,
> >+  /// which is a heuristic used for CSE'ing phys reg defs.
> >+  virtual unsigned getMachineCSELookAheadLimit () const {
> >+    // 5 is the value for this heuristic that used to be hard-coded into
> >+    // the MachineCSE pass.  I have no idea why 5 was choosen.
> >+    return 5;
> >+  }
> >+
> >  private:
> >    int CallFrameSetupOpcode, CallFrameDestroyOpcode;
> >  };
> >diff --git a/lib/CodeGen/MachineCSE.cpp b/lib/CodeGen/MachineCSE.cpp
> >index f72d72a..87aaaa0 100644
> >--- a/lib/CodeGen/MachineCSE.cpp
> >+++ b/lib/CodeGen/MachineCSE.cpp
> >@@ -48,7 +48,7 @@ namespace {
> >      MachineRegisterInfo *MRI;
> >    public:
> >      static char ID; // Pass identification
> >-    MachineCSE() : MachineFunctionPass(ID), LookAheadLimit(5), CurrVN(0) {
> >+    MachineCSE() : MachineFunctionPass(ID), LookAheadLimit(0), CurrVN(0) {
> >        initializeMachineCSEPass(*PassRegistry::getPassRegistry());
> >      }
> >@@ -69,7 +69,7 @@ namespace {
> >      }
> >    private:
> >-    const unsigned LookAheadLimit;
> >+    unsigned LookAheadLimit;
> >      typedef RecyclingAllocator<BumpPtrAllocator,
> >          ScopedHashTableVal<MachineInstr*, unsigned> > AllocatorTy;
> >      typedef ScopedHashTable<MachineInstr*, unsigned,
> >@@ -716,5 +716,6 @@ bool MachineCSE::runOnMachineFunction(MachineFunction &MF) {
> >    MRI = &MF.getRegInfo();
> >    AA = &getAnalysis<AliasAnalysis>();
> >    DT = &getAnalysis<MachineDominatorTree>();
> >+  LookAheadLimit = TII->getMachineCSELookAheadLimit();
> >    return PerformCSE(DT->getRootNode());
> >  }
> >diff --git a/lib/Target/R600/SIInstrInfo.h b/lib/Target/R600/SIInstrInfo.h
> >index 7e049dc..a654166 100644
> >--- a/lib/Target/R600/SIInstrInfo.h
> >+++ b/lib/Target/R600/SIInstrInfo.h
> >@@ -142,6 +142,8 @@ public:
> >    bool FoldImmediate(MachineInstr *UseMI, MachineInstr *DefMI,
> >                       unsigned Reg, MachineRegisterInfo *MRI) const final;
> >+  unsigned getMachineCSELookAheadLimit() const override { return UINT_MAX; }
> Using UINT_MAX for this seems like a bad idea

Do you have any idea what value we should be using?  I wasn't sure.

-Tom



More information about the llvm-commits mailing list