Overall, we make the flat representation of longs as a pair of (lo, hi) the representation, at the Emitter level. There are no more instances of RuntimeLong. The emitter flattens out all the Longs as follows:

• A local variable of type long becomes two local variables of type int.
• A field of type long becomes two fields of type int.
• An Array[Long] is stored as an Int32Array with twice as many elements, alternating lo and hi words.
• Method parameters of type long are expanded as two parameters of type int.

For the result of method parameters, there is a trick. That one is the most "debatable", in that I think there are contending alternatives that may be faster. When a method returns a Long, it stores the hi word in a global variable $resHi, then returns the lo word. At call site, we read back the $resHi global. We used a similar trick for non-inlined methods of RuntimeLong, with a var resultHi field of object RuntimeLong. Now this is moved to the emitter to take care of.

All the methods of RuntimeLong explicitly take "expanded" versions of their parameters: abs takes two parameters of type Int; add takes 4. Shifts take 3 parameters of type Int: the lo, the hi, and the shift amount. The result, however, is a Long.

In order to allow them to construct Long results from their words, we introduce a magic method RuntimeLong.pack(lo, hi), whose body is filled in by the Desugarer with a special Transient(PackLong(lo, hi)). It cannot be the compiler, because we cannot serialize transients. And it cannot wait for the emitter, because the optimizer definitely wants to see the PackLongs to unpack them. An alternative would be to introduce a new BinaryOp, but I think that's worse because it bakes an implementation detail of the emitter into the IR. The fact that we can even do this PR is a testament to the current abstraction level of our IR.

These changes significantly speed up even the SHA512 benchmark, even though it performs most computations on stack already anyway (the improvements must come from the arrays, in this case). I haven't measured benchmarks that extensively use Long fields yet, but I expect them to get dramatic speedups.

For the optimizer, this makes things a lot simpler. Instead of having special-cases for RuntimeLong everywhere, we basically have a unique withSplitLong method to deal with them. That method can split one PreTransform of type long into two PreTransforms of type ints, so that they can be given to the inlined methods of RuntimeLong. We introduce a new LongPairReplacement for LocalDefs that aggregate a pair of (lo, hi) LocalDefs (typically the result of a split PackLong). As a nice bonus, the IR checker now passes with RuntimeLong after the optimizer.

One big caveat for now: Closure breaks the new encoding, sometimes. I think it gets confused by the $resHi variable and evaluation order of function params. For example if we pass the result of a Long method to a Long parameter, we emit

x.foo(y.bar(1), $resHi);

During y.bar(1), the method modifies $resHi. It is then read right after to be passed as second argument to x.foo.