4 ms·

I clicked around a little, and it seems "icc 21.1.9", "x64 msvc x19.28", "risc-v clang (trunk)", "armv7-a clang (trunk)" compile it to four separate byte loads,

I clicked around a little, and it seems "icc 21.1.9", "x64 msvc x19.28", "risc-v clang (trunk)", "armv7-a clang (trunk)" compile it to four separate byte loads, it looks like. It's not that I don't trust my compiler (usually clang) to optimize it this way, it's just that the level of variability between compilers makes me think I shouldn't really rely on this behaving this way. I wonder what the arch difference is between the clangs that do it and the ones that don't, I don't know much about arm and risc-v.

user-the-name 6y ago
ARM does not support non-aligned reads, and can not safely change four byte loads into a one 32-bit load unless it can guarantee the address is aligned to 4 bytes. Not sure about RISC-V but I would not be surprised if the same applies there.
- shakna 6y ago
  > Not sure about RISC-V but I would not be surprised if the same applies there. It's probably a case of lowest common denominator. Unalligned access is discouraged but allowed by the spec... But it's allowed to raise an exception. But not required. Cheaper to optimise to avoid that circumstance.
- pm215 6y ago
  It used to be the case that Arm could not handle unaligned loads, but that functionality was added in v6 of the architecture (many years ago now) and so is present in most Arm cores around today including all the 64-bit ones. (Some instructions insist on aligned data, like atomic read-modify-write operations and some types of SIMD insn, but x86 has a few needs-alignment special cases too. Basic "just load/store data" insns that the compiler will emit are fine.)