Fix JIT bug related to immediate doubles

Change 256211 (JIT: Performance Fix for const doubles) introduced a
defect that can cause the JIT to use the wrong floating point
double constant in traces in which the following conditions hold:

   o Two (or more) different 64-bit floating point constants are used.
   o The physical register holding the first constant is still live
     at the time the second constant is used.
   o The low 32 bits of the two constants are identical.

In this situation, the load/copy optimization pass will incorrectly
determine that the two constants are the same, delete the load of
the second constant and re-use the first constant value.

Note: this problem only occurs with 64-bit floating point literals.
64-bit long literals are unaffected.

This CL works around the problem, and a subsequent CL will rework
disambiguation of 64-bit immediates in a somewhat cleaner fashion.

(cherry-pick of c1757a6deab0ca0bfd42c38612d92b2f26c41dbe.)

Change-Id: I795b4b753550d2745cbbdd83ae25f4a7088990f6

diff --git a/vm/compiler/codegen/arm/Thumb2/Factory.cpp b/vm/compiler/codegen/arm/Thumb2/Factory.cpp
index c3c3712..b9265e8 100644 (file)
--- a/vm/compiler/codegen/arm/Thumb2/Factory.cpp
+++ b/vm/compiler/codegen/arm/Thumb2/Factory.cpp
@@ -727,7 +727,8 @@ static ArmLIR *loadConstantValueWide(CompilationUnit *cUnit, int rDestLo,
             loadPcRel->operands[1] = r15pc;
             setupResourceMasks(loadPcRel);
             setMemRefType(loadPcRel, true, kLiteral);
-            loadPcRel->aliasInfo = dataTarget->operands[0];
+            // TODO: rework literal load disambiguation to more cleanly handle 64-bit loads
+            loadPcRel->aliasInfo = (uintptr_t)dataTarget;
             dvmCompilerAppendLIR(cUnit, (LIR *) loadPcRel);
             res =  loadPcRel;
         }