Option to truncate integers to 64 bits, part 1 (core VM changes)

runtime/platform/utils.h

Index: runtime/platform/utils.h
diff --git a/runtime/platform/utils.h b/runtime/platform/utils.h
index a1695d4b29117a4b4d5fa9dcd6c2606897c8f484..6569df75a546e999651c2a81475e17c55424c465 100644
--- a/runtime/platform/utils.h
+++ b/runtime/platform/utils.h
@@ -184,6 +184,45 @@ class Utils {
   }
 
 
+  // Adds two int64_t values with wrapping around
+  // (two's complement arithmetic).
+  static inline int64_t AddWithWrapAround(int64_t a, int64_t b) {
+    // Avoid UB by doing arithmetic in the unsigned type.

[regis, 2017/07/07 20:10:30]

What does UB stand for?

[alexmarkov, 2017/07/07 20:46:38]

UB = Undefined Behavior. Do you think I should avoid this acronym?

[regis, 2017/07/07 21:46:52]

You can spell it out for clarity. I did not know UB.

Now, these operations on unsigned operands only produce the correct result if an
overflow actually occurs. Should we assert that the signed operands create an
overflow? Maybe not necessary.
Example: if you multiply -1 by +1, the result will be +1, which is not correct
(no overflow). But the product of kMaxInt64 by -2 is -2, which is correct
because of the overflow. 

[alexmarkov, 2017/07/07 22:28:44]

Changed UB to "undefined behavior".

As far as I know, result should be correct regardless of the overflow (on all
systems which use two's complement arithmetic).

[regis, 2017/07/07 22:38:25]

Two's complement arithmetic can ignore the sign for addition and subtraction,
but not for multiplication and division. The sign can be ignored only if an
overflow occurs, i.e. the sign bit is at position > 63.
As mentioned, -1 * +1 should be -1, not +1.

[alexmarkov, 2017/07/07 23:17:58]

I agree about division, but still curious about multiplication.

If the high (64+) bits of the multiplication result are discarded, the low bits
(0..63) of the result should be the same regardless of signed or unsigned
multiplication (for the arguments with the same bit patterns). Note that sign
bit is not ignored - it is still taken into account during unsigned
multiplication.

In this particular case,
static_cast<uint64_t>(-1) = 0xffffffffffffffff
static_cast<uint64_t>(1) = 1
static_cast<uint64_t>(-1) * static_cast<uint64_t>(1) = 0xffffffffffffffff
static_cast<int64_t>(static_cast<uint64_t>(-1) * static_cast<uint64_t>(1)) = -1

So MulWithWrapAround(-1, 1) = -1, which looks correct.

Could you please clarify your doubts a little bit more?

+    return static_cast<int64_t>(static_cast<uint64_t>(a) +
+                                static_cast<uint64_t>(b));
+  }
+
+
+  // Subtracts two int64_t values with wrapping around
+  // (two's complement arithmetic).
+  static inline int64_t SubWithWrapAround(int64_t a, int64_t b) {
+    // Avoid UB by doing arithmetic in the unsigned type.
+    return static_cast<int64_t>(static_cast<uint64_t>(a) -
+                                static_cast<uint64_t>(b));
+  }
+
+
+  // Multiplies two int64_t values with wrapping around
+  // (two's complement arithmetic).
+  static inline int64_t MulWithWrapAround(int64_t a, int64_t b) {
+    // Avoid UB by doing arithmetic in the unsigned type.
+    return static_cast<int64_t>(static_cast<uint64_t>(a) *
+                                static_cast<uint64_t>(b));
+  }
+
+
+  // Shifts int64_t value left. Supports any non-negative number of bits and
+  // silently discards shifted out bits.
+  static inline int64_t ShiftLeftWithTruncation(int64_t a, int64_t b) {
+    ASSERT(b >= 0);
+    if (b >= kBitsPerInt64) {
+      return 0;
+    }
+    // Avoid UB by doing arithmetic in the unsigned type.
+    return static_cast<int64_t>(static_cast<uint64_t>(a) << b);
+  }
+
+
   // Utility functions for converting values from host endianness to
   // big or little endian values.
   static uint16_t HostToBigEndian16(uint16_t host_value);