llvm-mc treats .n suffix as .w suffix for ADC

[llvmbot]

Bugzilla Link	13803
Version	trunk
OS	Windows NT
Reporter	LLVM Bugzilla Contributor
CC	@compnerd,@john-brawn-arm,@kbeyls,@nickdesaulniers,@rprichard

Extended Description

Fails:

echo "adc.w r0, r1, #​1" | llvm-mc -triple=thumbv7 -show-encoding

Also fails for 'sbc.w' and its variants.

Workaround:

echo "adc r0, r1, #​1" | llvm-mc -triple=thumbv7 -show-encoding

Awkward workaround, use ".n", but it is still encoded with 32-bits:

echo "adc.n r0, r1, #​1" | llvm-mc -triple=thumbv7 -show-encoding

[compnerd]

This must be an extension. As per the ARM ARM:

ADC{S}.W , {, }

is what you are trying to use. is a register shift, which requires the shift type (LSL, LSR, ASR, ROR) or RRX for a non-constant applied.

Is there a strong reason to support this extension? Can you indicate what assemblers support this extension, and why you feel this is to support?

[john-brawn-arm]

The syntax for encoding T1 is ADC{S}.W, but the assembler syntax for ADC (immediate) is

ADC{S}{}{} {,} , #

where is .N or .W (page A8-301 of the ARMv7-A/R ARMARM revision C.c).

In the ARMARM the .W suffix is listed in the encoding if it's necessary to distinguish it from other encodings, but in the assembly syntax it's permitted even when it's not needed to distinguish between encodings (see section A8.2 "Standard assembler syntax fields").

[john-brawn-arm]

The syntax for encoding T1 is ADC{S}.W

Correction: that should have been "The syntax for encoding T2 of ADC (register) is ADC{S}.W"

[rprichard]

LLVM seems to be doing this:

• ".n" suffixes are ignored: "foo.n" is assembled just like "foo", even if "foo" is wide
• A ".w" suffix needs to be handled via a special alias in the assembler, and the alias support is spotty.

See bug #​50664, bug #​49118, https://gist.github.com/rprichard/2a601c3dd1b281f953b4e08b5a9361bb.

The GNU assembler instead seems to treat the ".n"/".w" suffix as a constraint. If the instruction could be encoded either way, then the assembler selects the encoding matching the suffix. Otherwise, if the suffix doesn't match the encoding, there's an assembler error. This behavior makes a lot more sense to me, but I'm not sure if there's an standard LLVM is trying to follow.