Remove MethodProtos/MethodBodies and allocation_order_begin/end.

Targets that need to change the default allocation order should use the
AltOrders mechanism instead. See the X86 and ARM targets for examples.

The allocation_order_begin() and allocation_order_end() methods have been
replaced with getRawAllocationOrder(), and there is further support
functions in RegisterClassInfo.

It is no longer possible to insert arbitrary code into generated
register classes. This is a feature.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@133332 91177308-0d34-0410-b5e6-96231b3b80d8

2 files changed, 1 insertions, 32 deletions

diff --git a/include/llvm/Target/Target.td b/include/llvm/Target/Target.td
index 915879202c..a0331705eb 100644
--- a/include/llvm/Target/Target.td
+++ b/include/llvm/Target/Target.td
@@ -133,12 +133,6 @@ class RegisterClass<string namespace, list<ValueType> regTypes, int alignment,
   // model instruction operand constraints, and should have isAllocatable = 0.
   bit isAllocatable = 1;
 
-  // MethodProtos/MethodBodies - These members can be used to insert arbitrary
-  // code into a generated register class.   The normal usage of this is to
-  // overload virtual methods.
-  code MethodProtos = [{}];
-  code MethodBodies = [{}];
-
   // AltOrders - List of alternative allocation orders. The default order is
   // MemberList itself, and that is good enough for most targets since the
   // register allocators automatically remove reserved registers and move
diff --git a/include/llvm/Target/TargetRegisterInfo.h b/include/llvm/Target/TargetRegisterInfo.h
index feb09292fe..840b048704 100644
--- a/include/llvm/Target/TargetRegisterInfo.h
+++ b/include/llvm/Target/TargetRegisterInfo.h
@@ -237,29 +237,6 @@ public:
     return SuperClasses[0] != 0;
   }
 
-  /// allocation_order_begin/end - These methods define a range of registers
-  /// which specify the registers in this class that are valid to register
-  /// allocate, and the preferred order to allocate them in.  For example,
-  /// callee saved registers should be at the end of the list, because it is
-  /// cheaper to allocate caller saved registers.
-  ///
-  /// These methods take a MachineFunction argument, which can be used to tune
-  /// the allocatable registers based on the characteristics of the function,
-  /// subtarget, or other criteria.
-  ///
-  /// Register allocators should account for the fact that an allocation
-  /// order iterator may return a reserved register and always check
-  /// if the register is allocatable (getAllocatableSet()) before using it.
-  ///
-  /// By default, these methods return all registers in the class.
-  ///
-  virtual iterator allocation_order_begin(const MachineFunction &MF) const {
-    return begin();
-  }
-  virtual iterator allocation_order_end(const MachineFunction &MF)   const {
-    return end();
-  }
-
   /// getRawAllocationOrder - Returns the preferred order for allocating
   /// registers from this register class in MF. The raw order comes directly
   /// from the .td file and may include reserved registers that are not
@@ -276,9 +253,7 @@ public:
   ///
   virtual
   ArrayRef<unsigned> getRawAllocationOrder(const MachineFunction &MF) const {
-    iterator B = allocation_order_begin(MF);
-    iterator E = allocation_order_end(MF);
-    return ArrayRef<unsigned>(B, E - B);
+    return ArrayRef<unsigned>(begin(), getNumRegs());
   }
 
   /// getSize - Return the size of the register in bytes, which is also the size