invalid operand for umov

[prabhatKrMishra]

:1:69: error: invalid operand for instruction
dup v1.4s, w14 ;movi v0.16b, #0 ;aese v0.16b, v1.16b ;umov w14, v0.4s[0] ;
^
LLVM ERROR: Error parsing inline asm

PLEASE submit a bug report to https://github.com/android-ndk/ndk/issues and include the crash backtrace.
Stack dump:
0. Program arguments: ld.lld --plugin-opt=O3 -O2 -r -o vmlinux.o -T .tmp_lto.lds --whole-archive built-in.o --no-whole-archive --start-group arch/arm64/lib/lib.a lib/lib.a --end-group

1.  Running pass 'Function Pass Manager' on module 'ld-temp.o'.
   

2.  Running pass 'AArch64 Assembly Printer' on function '@ce_aes_expandkey'
   

#0 0x00000000025af2f8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/home/pkm/ANDROID/kernel/tools/clang/host/linux-x86/clang-r407598/bin/lld+0x25af2f8)
#1 0x00000000025af180 llvm::sys::RunSignalHandlers() (/home/pkm/ANDROID/kernel/tools/clang/host/linux-x86/clang-r407598/bin/lld+0x25af180)
#2 0x00000000025af7bd (/home/pkm/ANDROID/kernel/tools/clang/host/linux-x86/clang-r407598/bin/lld+0x25af7bd)
#3 0x00007fccdefbf3c0 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x153c0)
#4 0x00007fccde9d018b raise /build/glibc-eX1tMB/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:51:1
#5 0x00007fccde9af859 abort /build/glibc-eX1tMB/glibc-2.31/stdlib/abort.c:81:7
#6 0x0000000002585e0c (/home/pkm/ANDROID/kernel/tools/clang/host/linux-x86/clang-r407598/bin/lld+0x2585e0c)
#7 0x0000000002582d47 (/home/pkm/ANDROID/kernel/tools/clang/host/linux-x86/clang-r407598/bin/lld+0x2582d47)
#8 0x00000000018608f7 (/home/pkm/ANDROID/kernel/tools/clang/host/linux-x86/clang-r407598/bin/lld+0x18608f7)
#9 0x000000000185fe82 llvm::AsmPrinter::emitInlineAsm(llvm::MachineInstr const*) const (/home/pkm/ANDROID/kernel/tools/clang/host/linux-x86/clang-r407598/bin/lld+0x185fe82)
#10 0x000000000185d587 llvm::AsmPrinter::emitFunctionBody() (/home/pkm/ANDROID/kernel/tools/clang/host/linux-x86/clang-r407598/bin/lld+0x185d587)
#11 0x00000000027a8ba4 (/home/pkm/ANDROID/kernel/tools/clang/host/linux-x86/clang-r407598/bin/lld+0x27a8ba4)
#12 0x0000000001f6a729 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (/home/pkm/ANDROID/kernel/tools/clang/host/linux-x86/clang-r407598/bin/lld+0x1f6a729)
#13 0x0000000001975264 llvm::FPPassManager::runOnFunction(llvm::Function&) (/home/pkm/ANDROID/kernel/tools/clang/host/linux-x86/clang-r407598/bin/lld+0x1975264)
#14 0x0000000001974f7f llvm::FPPassManager::runOnModule(llvm::Module&) (/home/pkm/ANDROID/kernel/tools/clang/host/linux-x86/clang-r407598/bin/lld+0x1974f7f)
#15 0x0000000002299be4 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/home/pkm/ANDROID/kernel/tools/clang/host/linux-x86/clang-r407598/bin/lld+0x2299be4)
#16 0x0000000002ac1d2a (/home/pkm/ANDROID/kernel/tools/clang/host/linux-x86/clang-r407598/bin/lld+0x2ac1d2a)
#17 0x0000000002ab7e98 llvm::lto::backend(llvm::lto::Config const&, std::__1::function<std::__1::unique_ptr<llvm::lto::NativeObjectStream, std::__1::default_deletellvm::lto::NativeObjectStream > (unsigned int)>, unsigned int, std::__1::unique_ptr<llvm::Module, std::__1::default_deletellvm::Module >, llvm::ModuleSummaryIndex&) (/home/pkm/ANDROID/kernel/tools/clang/host/linux-x86/clang-r407598/bin/lld+0x2ab7e98)
#18 0x0000000002ab6fed llvm::lto::LTO::runRegularLTO(std::__1::function<std::__1::unique_ptr<llvm::lto::NativeObjectStream, std::__1::default_deletellvm::lto::NativeObjectStream > (unsigned int)>) (/home/pkm/ANDROID/kernel/tools/clang/host/linux-x86/clang-r407598/bin/lld+0x2ab6fed)
#19 0x00000000020b7a0e llvm::lto::LTO::run(std::__1::function<std::__1::unique_ptr<llvm::lto::NativeObjectStream, std::__1::default_deletellvm::lto::NativeObjectStream > (unsigned int)>, std::__1::function<std::__1::function<std::__1::unique_ptr<llvm::lto::NativeObjectStream, std::__1::default_deletellvm::lto::NativeObjectStream > (unsigned int)> (unsigned int, llvm::StringRef)>) (/home/pkm/ANDROID/kernel/tools/clang/host/linux-x86/clang-r407598/bin/lld+0x20b7a0e)
#20 0x00000000020a5879 lld::elf::BitcodeCompiler::compile() (/home/pkm/ANDROID/kernel/tools/clang/host/linux-x86/clang-r407598/bin/lld+0x20a5879)
#21 0x0000000002098e58 void lld::elf::LinkerDriver::compileBitcodeFiles<llvm::object::ELFType<(llvm::support::endianness)1, true> >() (/home/pkm/ANDROID/kernel/tools/clang/host/linux-x86/clang-r407598/bin/lld+0x2098e58)
#22 0x0000000002087aa8 void lld::elf::LinkerDriver::link<llvm::object::ELFType<(llvm::support::endianness)1, true> >(llvm::opt::InputArgList&) (/home/pkm/ANDROID/kernel/tools/clang/host/linux-x86/clang-r407598/bin/lld+0x2087aa8)
#23 0x0000000002073e83 lld::elf::LinkerDriver::main(llvm::ArrayRef<char const*>) (/home/pkm/ANDROID/kernel/tools/clang/host/linux-x86/clang-r407598/bin/lld+0x2073e83)
#24 0x00000000020723b9 lld::elf::link(llvm::ArrayRef<char const*>, bool, llvm::raw_ostream&, llvm::raw_ostream&) (/home/pkm/ANDROID/kernel/tools/clang/host/linux-x86/clang-r407598/bin/lld+0x20723b9)
#25 0x0000000002071a4b (/home/pkm/ANDROID/kernel/tools/clang/host/linux-x86/clang-r407598/bin/lld+0x2071a4b)
#26 0x00000000020717b9 main (/home/pkm/ANDROID/kernel/tools/clang/host/linux-x86/clang-r407598/bin/lld+0x20717b9)
#27 0x00007fccde9b10b3 __libc_start_main /build/glibc-eX1tMB/glibc-2.31/csu/../csu/libc-start.c:342:3
#28 0x00000000033a1401 _start (/home/pkm/ANDROID/kernel/tools/clang/host/linux-x86/clang-r407598/bin/lld+0x33a1401)
../scripts/link-vmlinux.sh: line 101: 529200 Aborted ${LD} ${LDFLAGS} -r -o ${1} $(lto_lds) ${objects}

[prabhatKrMishra]

I cherry-picked commits from here for Clang LTO support. https://github.com/mvaisakh/android_kernel_asus_sdm660/tree/clang-LTO
Commit start from mvaisakh/android_kernel_asus_sdm660@240802f
and end to mvaisakh/android_kernel_asus_sdm660@1382a1b
My kernel version is 4.4.205.

[nickdesaulniers]

android/ndk#1511 (comment)

[nickdesaulniers]

@pkm774 please let me know if cherry-picking 019cd46 resolves the issue for you or not.

[nickdesaulniers]

Either way, it seems that LLVM has trouble with

$ cat foo.s 
umov w14, v0.4s[0]
$ aarch64-linux-gnu-as foo.s
$ aarch64-linux-gnu-objdump -d a.out

a.out:     file format elf64-littleaarch64

Disassembly of section .text:

0000000000000000 <.text>:
   0:   0e043c0e        mov     w14, v0.s[0]
$ clang --target=aarch64-linux-gnu foo.s 
foo.s:1:11: error: invalid operand for instruction
umov w14, v0.4s[0]
          ^

[prabhatKrMishra]

Yeah cherry-picking 019cd46 fixed the problem

[nickdesaulniers]

I was reading this the other day, and it reminded me of my comment above. @jcai19 can you please see if that snippet is something we're missing support for in LLVM? It might be worthwhile to discuss more with @kbeyls if so.

FWIW 019cd46 first landed in v4.16-rc1. (We don't have a label for that older kernel version, but that doesn't matter).

[DavidSpickett]

This caught my eye. Maybe what I found can help some.

umov is supposed to have an "element size specifier": https://developer.arm.com/documentation/ddi0602/latest/SIMD-FP-Instructions/UMOV--Unsigned-Move-vector-element-to-general-purpose-register-?lang=en#sa_ts

Which would be "v0.[bshd]", no number after the dot.

I found that clang does allow this for uaddl/uaddl2: https://developer.arm.com/documentation/dui0802/b/A64-SIMD-Vector-Instructions/UADDL--UADDL2--vector-

The interesting part is that the description of that refers to them as an "arrangement specifier" and has a table of allowed combinations.

My assumption is that GAS allows you to use this arrangement style even with instructions that don't have it. When I tried it myself, there was some set of combinations that would work but it did not effect the encoding of the instruction. (which makes sense, there's no field for it)

Probably a good case to add the same leniency to llvm but you'll need to work out what GAS' logic is for what it allows.

My naive assumption was that anything where number x size == 128 would be fine, but I think I'm simplifying what an "arrangement specifier" is too much.

For example these three are accepted by GAS:

umov w14, v0.b[0]
umov w14, v0.8b[0]
umov w14, v0.16b[0]

(I also checkout out our proprietary "armasm" tool, it does not appear to support it but then again it tends to be more letter of the law)

[nickdesaulniers]

Closing for now. Happy to reopen if this becomes relevant again.