It appears that when we emit constant loads (with the constants embedded in pools in the instruction stream) we can end up in a situation where we load an 8-byte constant from a 4-byte aligned address. At least I've run across this when we emit loads of code pointer for the debug traps. In GDB the code disassembles like this: 0x9c65b8cbbd0: ldr x17, 0x9c65b8cbc44 0x9c65b8cbbd4: nop though in reality the operand in the first instruction is pc+immediate. Note the address is not 8-byte divisible. Whether this is allowed is actually implementation dependent and is controlled by a bit in the status word (SCTRL_EL1.A). Unaligned loads may be supported directly by the chip or may be handled by the OS or may trap. I don't think there's any reason why we should not align constants on their natural boundaries, though I don't know how much surgery is required. Doing so would probably be good for performance in any case, and would reduce implementation dependencies. (Unclear impact for aarch32, if indeed it is an issue there. Generally aarch32 has required only 4-byte alignment even for 8-byte data.)