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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
