[clang] [clang][driver] Allow unaligned access on ARMv7 and higher by default (PR #82400)

[David Green via cfe-commits]

https://github.com/davemgreen commented:

> Unaligned accesses require that SCTLR.A is 0, SCTLR.U is 1, and that the memory in question is configured as "normal" memory. Almost all operating systems do in fact configure their registers/memory this way, but on baremetal it's not really a safe assumption. Changing the default here is basically guaranteed to break someone's code.
> 
> We could make the value judgement that the performance gain outweighs breaking someone's code. Disabled unaligned access is a performance hit users have a hard time discovering; incorrectly enabled unaligned access will generate an obvious alignment fault on v7 and up.
> 
> On pre-v7 processors, you can get the old "rotate" behavior instead of a fault. This is controlled by SCTLR.U on v6, but I don't think there's any reason to expect the bit is configured the "right" way on baremetal. So changing the default for v6 is a bit more dubious.
> 
> The tradeoffs might be a bit different for M-class processors; I think unaligned access works by default there (except for v6m and v8m.baseline).
> 
> This change needs a release note.

The issue that we have found is that as both GCC and Arm Compiler default to -munaligned-access, users expect it to be the default. They only notice the much bigger codesize/worse performance and don't understand the reason without a lot of digging. You are certainly right that someone who has been using clang bare metal in the past might hit problems with the new default, but there is a high chance they are just using the wrong option without noticing. And I believe aligning with GCC/Arm Compiler is a better default going forward, as more people start using Clang in bare metal. Hopefully the release note can at least make it clear.

M-Profile needs a bit set in the bootcode, IIRC.

https://github.com/llvm/llvm-project/pull/82400