Register promotion support for 64-bit targets

Not sufficiently tested for 64-bit targets, but should be
fairly close.

A significant amount of refactoring could stil be done, (in
later CLs).

With this change we are not making any changes to the vmap
scheme.  As a result, it is a requirement that if a vreg
is promoted to both a 32-bit view and the low half of a
64-bit view it must share the same physical register.  We
may change this restriction later on to allow for more flexibility
for 32-bit Arm.

For example, if v4, v5, v4/v5 and v5/v6 are all hot enough to
promote, we'd end up with something like:

v4 (as an int)    -> r10
v4/v5 (as a long) -> r10
v5 (as an int)    -> r11
v5/v6 (as a long) -> r11

Fix a couple of ARM64 bugs on the way...

Change-Id: I6a152b9c164d9f1a053622266e165428045362f3

1 files changed, 9 insertions, 2 deletions

diff --git a/compiler/dex/reg_storage.h b/compiler/dex/reg_storage.h
index 3b891f2f20..8ed3adc1f1 100644
--- a/compiler/dex/reg_storage.h
+++ b/compiler/dex/reg_storage.h
@@ -122,11 +122,18 @@ class RegStorage {
   constexpr explicit RegStorage(uint16_t val) : reg_(val) {}
   RegStorage() : reg_(kInvalid) {}
 
-  bool operator==(const RegStorage rhs) const {
+  // We do not provide a general operator overload for equality of reg storage, as this is
+  // dangerous in the case of architectures with multiple views, and the naming ExactEquals
+  // expresses the exact match expressed here. It is more likely that a comparison between the views
+  // is intended in most cases. Such code can be found in, for example, Mir2Lir::IsSameReg.
+  //
+  // If you know what you are doing, include reg_storage_eq.h, which defines == and != for brevity.
+
+  bool ExactlyEquals(const RegStorage& rhs) const {
     return (reg_ == rhs.GetRawBits());
   }
 
-  bool operator!=(const RegStorage rhs) const {
+  bool NotExactlyEquals(const RegStorage& rhs) const {
     return (reg_ != rhs.GetRawBits());
   }