ARM can perform 64-bit integer loads and stores using LDRD and STRD. These will be ideal for handling fatvals. However, for ARM code at least, there is one significant restriction: The registers used must be adjacent and aligned (like r0-r1, but not r1-r2). In order to make use of this on ARM, the register allocator needs to be able to find adjacent registers. Also, the scratch register set should really put two scratch registers next to each other so the back-end can issue LDRD and STRD even if JM specifies awkward arguments (like immediates).

A good example, from InjectJaegerReturn: "ldr r1, [r11, #40]" "\n" /* fp->rval data */ "ldr r2, [r11, #44]" "\n" /* fp->rval type */ If a more suitable register pair were used (such as r2+r3), the following would be preferable: "ldrd r2, r3, [r11, #40]" "\n" It should be too hard to re-assign S0 to r1 and use r2-r3 for the data/type pair.

This patch makes very little difference to performance with either SunSpider or V8 (on A9 at least). I think the LDRD sequence is faster than the old LDR-based one, but I've reserved an extra scratch register for some variants so that probably negates any benefit. Also note that I haven't changed the register allocation patterns, so we won't be making use of all the new code-paths. I'll investigate further at some point.

If the register allocator is not nice to us, in some cases, we can produce more efficent code using the writeback bit. I am explicitly thinking of the code generated by load64WithAddressOffsetPatch which looks like: ldr s0, c addr s0, s0, r_base ldr dest1, [s0] ldr dest2, [s0,4] We should be able to eliminate the add by: ldr s0, c ldr dest1, [s0, r_base]! ldr dest2, [s0,4] I suspect that this in particular won't help by a huge amount, but there are likely other places that we can apply this.

Does IM's ARM backend do this?

yes, and no. IM's backend has the ability to emit ldrd for loading a value, but it requires the register allocator to allocate the two halves of a value in two consecutive registers, with the even register being lower *and* the tag needs to go in the higher register. Unfortunately, from the examples that I've looked at (several months ago at this point), the register allocator always puts the tag in the lower register, meaning we almost never actually use this instruction. Other hair-brained ideas that I mentioned in this bug have not been implemented for IM.

Given comment 5, I'm changing the description to tag ion.