[BUG] clang assembler missing some neon opcodes

[vadimw2qcom]

---

Description

clang doesn't support compiling the assembler specifically build for 32 bit arm neon architecture, and it does not detect some opcodes. In order for me to correctly compile assembler code which was optimized for 32 bit arm Neon, I have to go back to r10e which is based on the gcc version rather than clang.

Examples for those opcodes are: Name directives: im1 .dn d0 re1 .dn d1

Unrecognized instructions: vmull.s16 yr, re1, re2 vmlal.s16 yr, im1, im2 vqrshrn.s32 zi, yi, #15 vqrshrn.s32 zr, yr, #15 reference to neon and vfp instructions. http://infocenter.arm.com/help/topic/com.arm.doc.dui0473j/dom1361289932816.html

It would be nice if future version would support neon optimized assembler.

Not all of these will be relevant to every bug, but please provide as much information as you can.

• NDK Version: r19

• Build system: ndk-build

• Host OS: Linux Ubuntu 18

• ABI:

• NDK API level:

APP_ABI := armeabi-v7a arm64-v8a APP_PLATFORM:=21

[DanAlbert]

A few questions just to make sure this is a Clang bug:

1. Are you actually building for Neon? That's not on by default (until r21) for the configuration you've named (not the 32-bit config, anyway)
2. Are you using the integrated assembler, or GAS? (have you manually set -fno-integrated-as?)

@stephenhines FYI

[stephenhines]

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.100069_0612_00_en/pge1424879061935.html says the syntax is "DN" vs. ".dn", but that appears to be an ARM assembler-specific directive that is not available in Clang. I will file a bug about that in the morning. As for the mnemonics, @vadimw2qcom, can you give me a test case that fails for those without using your .dn directives? From my own understanding of the Clang code, vmull.s16 (and the others) seem like they are all supported in Clang. It could also be due to Dan't suggestion for enabling NEON when assembling these sources.

[vadimw2qcom]

Hi, Thank you for the reply. Attached is the problematic input file, and output error file from the compiler r19. Below are the command lines that executes the files.

Here is the command line that works for r10e: /usr/lib/android-ndk-r10e/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64/bin/arm-linux-androideabi-gcc -MMD -MP -MF ./obj/local/armeabi-v7a/objs/dsplib/vector_mul_conj_sc16.o.d -fpic -ffunction-secti ons -funwind-tables -fstack-protector -no-canonical-prefixes -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=softfp -O2 -g -DNDEBUG -fomit-frame-pointer -fstrict-aliasing -funswitch-loops -finline-limit=300 -Ijni/../ ../dsplib/arm/.. -Ijni/../../dsplib/arm -DANDROID -std=c99 -mfpu=neon -Wa,--noexecstack -Wformat -Werror=format-security -I/usr/lib/android-ndk-r10e/platforms/android-21/arch-arm/usr/include -c jni/../../dsp lib/arm/vector_mul_conj_sc16.S -o ./obj/local/armeabi-v7a/objs/dsplib/vector_mul_conj_sc16.o

Here is the command line that fails for r19: /usr/lib/android-ndk-r19/toolchains/llvm/prebuilt/linux-x86_64/bin/clang -MMD -MP -MF ./obj/local/armeabi-v7a/objs/dsplib/vector_mul_conj_sc16.o.d -target armv7-none-linux-androideabi16 -fdata-sections -ffunction-sections -fstack-protector-strong -funwind-tables -no-canonical-prefixes --sysroot /usr/lib/android-ndk-r19/toolchains/llvm/prebuilt/linux-x86_64/sysroot -g -Wno-invalid-command-line-argument -Wno-unused-command-line-argument -fno-addrsig -fpic -mfpu=vfpv3-d16 -O2 -DNDEBUG -Ijni/../../dsplib/arm/.. -Ijni/../../dsplib/arm -DANDROID -std=c99 -mfpu=neon -Wa,--noexecstack -Wformat -Werror=format-security -c jni/../../dsplib/arm/vector_mul_conj_sc16.S -o ./obj/local/armeabi-v7a/objs/dsplib/vector_mul_conj_sc16.o

From: stephenhines notifications@github.com Sent: Thursday, September 26, 2019 12:30 AM To: android/ndk ndk@noreply.github.com Cc: Vadim Winebrand vadimw@qti.qualcomm.com; Mention mention@noreply.github.com Subject: [EXT] Re: [android/ndk] [BUG] (#1086)

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.100069_0612_00_en/pge1424879061935.html says the syntax is "DN" vs. ".dn", but that appears to be an ARM assembler-specific directive that is not available in Clang. I will file a bug about that in the morning. As for the mnemonics, @vadimw2qcomhttps://github.com/vadimw2qcom, can you give me a test case that fails for those without using your .dn directives? From my own understanding of the Clang code, vmull.s16 (and the others) seem like they are all supported in Clang. It could also be due to Dan't suggestion for enabling NEON when assembling these sources.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/android/ndk/issues/1086?email_source=notifications&email_token=ANJ43M5NO7CVSAIW46BZC53QLRQHXA5CNFSM4I2U6MX2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7UTKVY#issuecomment-535377239, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ANJ43M4TMJ6BBKO5KOXK3MDQLRQHXANCNFSM4I2U6MXQ.

jni/../../dsplib/arm/vector_mul_conj_sc16.S:22:9: error: unexpected token in argument list im1 .dn d0 ^ jni/../../dsplib/arm/vector_mul_conj_sc16.S:23:9: error: unexpected token in argument list re1 .dn d1 ^ jni/../../dsplib/arm/vector_mul_conj_sc16.S:24:9: error: unexpected token in argument list im2 .dn d2 ^ jni/../../dsplib/arm/vector_mul_conj_sc16.S:25:9: error: unexpected token in argument list re2 .dn d3 ^ jni/../../dsplib/arm/vector_mul_conj_sc16.S:26:8: error: unexpected token in argument list yi .qn q2 ^ jni/../../dsplib/arm/vector_mul_conj_sc16.S:27:8: error: unexpected token in argument list yr .qn q3 ^ jni/../../dsplib/arm/vector_mul_conj_sc16.S:28:8: error: unexpected token in argument list zi .dn d4 ^ jni/../../dsplib/arm/vector_mul_conj_sc16.S:29:8: error: unexpected token in argument list zr .dn d5 ^ jni/../../dsplib/arm/vector_mul_conj_sc16.S:30:9: error: unexpected token in argument list md1 .dn d0 ^ jni/../../dsplib/arm/vector_mul_conj_sc16.S:31:13: error: unexpected token in argument list output1 .dn d2 ^ jni/../../dsplib/arm/vector_mul_conj_sc16.S:32:13: error: unexpected token in argument list output2 .dn d3 ^

:17:5: error: unknown directive .func vector_mul_conj_sc16 ^ jni/../../dsplib/arm/vector_mul_conj_sc16.S:36:5: note: while in macro instantiation func vector_mul_conj_sc16 ^ jni/../../dsplib/arm/vector_mul_conj_sc16.S:37:15: error: register expected vld2.s16 {im1, re1}, [in1]! ^ jni/../../dsplib/arm/vector_mul_conj_sc16.S:38:15: error: register expected vld2.s16 {im2, re2}, [in2]! ^ jni/../../dsplib/arm/vector_mul_conj_sc16.S:43:5: error: invalid instruction vmull.s16 yi, im1, re2 ^ jni/../../dsplib/arm/vector_mul_conj_sc16.S:44:5: error: invalid instruction vmlsl.s16 yi, re1, im2 ^ jni/../../dsplib/arm/vector_mul_conj_sc16.S:45:5: error: invalid instruction vmull.s16 yr, re1, re2 ^ jni/../../dsplib/arm/vector_mul_conj_sc16.S:46:5: error: invalid instruction vmlal.s16 yr, im1, im2 ^ jni/../../dsplib/arm/vector_mul_conj_sc16.S:47:5: error: invalid instruction vqrshrn.s32 zi, yi, #15 ^ jni/../../dsplib/arm/vector_mul_conj_sc16.S:48:5: error: invalid instruction vqrshrn.s32 zr, yr, #15 ^ jni/../../dsplib/arm/vector_mul_conj_sc16.S:49:15: error: register expected vld2.s16 {im1, re1}, [in1]! ^ jni/../../dsplib/arm/vector_mul_conj_sc16.S:50:15: error: register expected vld2.s16 {im2, re2}, [in2]! ^ jni/../../dsplib/arm/vector_mul_conj_sc16.S:51:15: error: register expected vst2.s16 {zi, zr}, [out]! ^ jni/../../dsplib/arm/vector_mul_conj_sc16.S:58:5: error: invalid instruction vmull.s16 yi, im1, re2 ^ jni/../../dsplib/arm/vector_mul_conj_sc16.S:59:5: error: invalid instruction vmlsl.s16 yi, re1, im2 ^ jni/../../dsplib/arm/vector_mul_conj_sc16.S:60:5: error: invalid instruction vmull.s16 yr, re1, re2 ^ jni/../../dsplib/arm/vector_mul_conj_sc16.S:61:5: error: invalid instruction vmlal.s16 yr, im1, im2 ^ jni/../../dsplib/arm/vector_mul_conj_sc16.S:62:5: error: invalid instruction vqrshrn.s32 zi, yi, #15 ^ jni/../../dsplib/arm/vector_mul_conj_sc16.S:63:5: error: invalid instruction vqrshrn.s32 zr, yr, #15 ^ jni/../../dsplib/arm/vector_mul_conj_sc16.S:64:15: error: register expected vld1.s16 {md1}, [m] ^ jni/../../dsplib/arm/vector_mul_conj_sc16.S:65:15: error: register expected vld2.s16 {output1, output2}, [out] ^ jni/../../dsplib/arm/vector_mul_conj_sc16.S:66:5: error: invalid instruction vbif.s16 zi, output1, md1 ^ jni/../../dsplib/arm/vector_mul_conj_sc16.S:67:5: error: invalid instruction vbif.s16 zr, output2, md1 ^ jni/../../dsplib/arm/vector_mul_conj_sc16.S:68:15: error: register expected vst2.s16 {zi, zr}, [out] ^ :5:5: error: unknown directive .endfunc ^ jni/../../dsplib/arm/vector_mul_conj_sc16.S:71:5: note: while in macro instantiation endf ^

[vadimw2qcom]

I'm attaching the files in case they are not seen from the email reply. I renamed the file vector_mul_conj_sc16.S to vector_mul_conj_sc16.txt because GitHub doesn't recognize the .S extensions.

output.txt

vector_mul_conj_sc16.txt

[vadimw2qcom]

It seems the issue was resolved all I had to do is to add the following line: LOCAL_ASFLAGS := -fno-integrated-as in the Android.mk and now it perfectly compiles

[DanAlbert]

Glad to know there's a workaround.

I think I heard the LLVM folks are trying to improve compatibility for the assembler, so I'll reopen this to track that.

[enh-google]

did an upstream bug actually get filed for this?

[DanAlbert]

@stephenhines @pirama-arumuga-nainar any idea if a bug got filed for this? Or maybe it's been fixed?

[stephenhines]

No upstream bug was filed for this. As I see it, there are a few issues here with the integrated assembler, but I think that @vadimw2qcom should actually file the upstream bug directly with LLVM (https://bugs.llvm.org/). The source file has a copyright and proprietary notice that I'm not comfortable recopying into another bug tracker. You're likely to get better traction from ARM via upstream LLVM than Google requesting this on your behalf, since Qualcomm is a large customer of ARM. You should also probably contact any internal technical account manager (TAM) that handles your ARM relationship to further track progress on that bug. If you do end up filing an upstream bug, please feel free to let us know here, and we can follow up with our contacts too, especially since the missing neon syntax may be affecting other NDK users too.

[DanAlbert]

Closing here as "nothing we can do" rather than "fixed". Please do update with an upstream bug if one gets filed.