-mcpu=cortex-m33 does not set -munaligned-access

[taralx]

Cortex-M33 is ARMv8-M Mainline, which supports unaligned access unless explicitly disabled. It appears to be correct in ARM.td, but as you can see below the output depends on the flag being explictly passed.

Test case:

int ttt(short a[2], short b[2]) {
  return (int)a[0] * (int)b[0] + (int)a[1] * (int)b[1];
}

Output with clang --target=arm-none-eabi -mcpu=cortex-m33 -O3 -S -o- testcase.c:

	ldrsh.w	r2, [r0]
	ldrsh.w	r0, [r0, #2]
	ldrsh.w	r3, [r1, #2]
	ldrsh.w	r1, [r1]
	muls	r0, r3, r0
	smlabb	r0, r1, r2, r0
	bx	lr

Output with clang --target=arm-none-eabi -mcpu=cortex-m33 -munaligned-access -O3 -S -o- testcase.c:

	ldr	r0, [r0]
	ldr	r1, [r1]
	movs	r2, #0
	smlad	r0, r1, r0, r2
	bx	lr

Version: Homebrew clang version 15.0.6

[llvmbot]

@llvm/issue-subscribers-backend-aarch64

[llvmbot]

@llvm/issue-subscribers-clang-driver

[llvmbot]

@llvm/issue-subscribers-backend-arm

[lenary]

This is due to the following code, which has a long comment:

llvm-project/clang/lib/Driver/ToolChains/Arch/ARM.cpp

Lines 808 to 832 in 2c5d49c

	// Assume pre-ARMv6 doesn't support unaligned accesses.
	//
	// ARMv6 may or may not support unaligned accesses depending on the
	// SCTLR.U bit, which is architecture-specific. We assume ARMv6
	// Darwin and NetBSD targets support unaligned accesses, and others don't.
	//
	// ARMv7 always has SCTLR.U set to 1, but it has a new SCTLR.A bit
	// which raises an alignment fault on unaligned accesses. Linux
	// defaults this bit to 0 and handles it as a system-wide (not
	// per-process) setting. It is therefore safe to assume that ARMv7+
	// Linux targets support unaligned accesses. The same goes for NaCl
	// and Windows.
	//
	// The above behavior is consistent with GCC.
	int VersionNum = getARMSubArchVersionNumber(Triple);
	if (Triple.isOSDarwin() || Triple.isOSNetBSD()) {
	if (VersionNum < 6 ||
	Triple.getSubArch() == llvm::Triple::SubArchType::ARMSubArch_v6m)
	Features.push_back("+strict-align");
	} else if (Triple.isOSLinux() || Triple.isOSNaCl() ||
	Triple.isOSWindows()) {
	if (VersionNum < 7)
	Features.push_back("+strict-align");
	} else
	Features.push_back("+strict-align");

In short, if you were using an OS like linux in your triple, then clang wouldn't assume that you need -mno-unaligned-access.

Looking at your example in Compiler Explorer, GCC (for the none OS) follows the same choices, so presumably the comment is fairly up to date. GCC for linux seems more pessimistic than clang in this instance.

I'm not in total agreement that all v8m.mainline cores support unaligned access. Rule JLGS says "unaligned accesses are only supported if the main extension is implemented", which seems to have the opposite implication: if you have unaligned accesses, you have main, not the other way around. Though I also see that CCR.UNALIGN_TRP resets to 0 if the main extension is implemented, which would seem to be the opposite implication direction to RJLGS.

In ARM.td, we don't have a feature for "Supports Unaligned Access", we only have FeatureStrictAlign which is the opposite. Given the complex logic in the driver, this seems wise.

[taralx]

I think you have the right of it. Rule JLGS doesn't govern here, but rule MHCM does -- it delegates to CCR.UNALIGN_TRP, which has to reset to zero in mainline implementations. Additional support is in the implementation of MemU, which also delegates to CCR.UNALIGN_TRP for mainline implementations.

[davemgreen]

I had noticed this recently and created an internal ticket for changing the default. (I'm not sure when this will be tackled though). The exact CPU shouldn't matter, the important part is that the v7m architecture and beyond can support unaligned access, and it makes a better default than assuming they are unsupported. They usually get enabled in the bootcode without much hassle.

Both GCC and Arm's downstream embedded armclang compiler use -munaligned-access by default. I'm not sure why this was not done upstream but it would make sense to do so. Clangs default should be the same, where users can opt out by using -mno-unaligned-access.