JavaScript:SpiderMonkey:AArch64

AArch 64 Overview

• Use Punboxing, arm uses few enough bits of pointers that we don't even need to do anything tricky
• No AFC (Initially). Since the flushing instructions are available to userspace programs, we don't have the kernel overhead, so there shouldn't be as painful a hit to flushing the cache all the time.
• No fancy constant pools needed (Should still use the current/new AssemblerBuffer backend). The only code that GCC generates loads for is floating point constants. Loads seem to get a whopping 19 bits of offset, good for 512kb of pc-relative offset. Unfortunately, this means that any code that does force a pool spill at an awkward location will in fact be very large and unweildy.
• Lowering and codegen should be straightforward from arm/x64-
• No changes to regalloc should be necessary, there isn't aliasing on the ieee registers.
• I'm expecting a sizeable chunk of code to deal with encoding immediates.
• The Zero register and the Stack pointer share an encoding. There will be two different encodings until right before code generation, when we assert that the use fits the instruction.
• It looks like there are a few differnt encodings for load to choose from.
• I'm imagining a continuation of the current arm-assembler, where there is one C++-class per instruction (roughly broken down by how the instructions are mentioned in the ARM ARM). This should enable us to do useful things like ask "can I encode this offset in this instruction", returning either an Instruction *, or null_ptr, if you can't encode it.

Future Optimizations

• Generate conditional instructions more
• merge parts of constants
• Generate MADD (also useful for aarch32)
• Generate shift-alu ops (also useful for aarch32)
• Generate prefetches
• Bitfield instructions