Open kleisauke opened 1 year ago
@llvm/issue-subscribers-backend-arm
This doesn't seem to be a regression; I can reproduce this with at least Clang 14.
CC @dpaoliello
This also seems to affect SVE intrinsics on Arm64 (AArch64).
$ docker run --rm -v $(pwd):/repro -w /repro -it mstorsjo/llvm-mingw:latest aarch64-w64-mingw32-clang -march=armv8.2-a+sve -O1 -g -gcodeview -c reduced.c
fatal error: error in backend: unknown codeview register Z0
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0. Program arguments: /opt/llvm-mingw/bin/clang --start-no-unused-arguments -target aarch64-w64-mingw32 -rtlib=compiler-rt -unwindlib=libunwind -stdlib=libc++ -fuse-ld=lld --end-no-unused-arguments -march=armv8.2-a+sve -O1 -g -gcodeview -c reduced.c
1. <eof> parser at end of file
2. Code generation
3. Running pass 'Function Pass Manager' on module 'reduced.c'.
4. Running pass 'AArch64 Assembly Printer' on function '@aom_sum_squares_2d_i16_wxh_sve'
#0 0x00007f07722b1180 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/llvm-mingw/bin/../lib/libLLVM.so.18.1+0x85c180)
#1 0x00007f07722af054 llvm::sys::CleanupOnSignal(unsigned long) (/opt/llvm-mingw/bin/../lib/libLLVM.so.18.1+0x85a054)
#2 0x00007f07721b21d7 llvm::CrashRecoveryContext::HandleExit(int) (/opt/llvm-mingw/bin/../lib/libLLVM.so.18.1+0x75d1d7)
#3 0x00007f07722a65d2 llvm::sys::Process::Exit(int, bool) (/opt/llvm-mingw/bin/../lib/libLLVM.so.18.1+0x8515d2)
#4 0x00005573e2e3b4a7 (/opt/llvm-mingw/bin/clang+0x124a7)
#5 0x00007f07721c6c50 llvm::report_fatal_error(llvm::Twine const&, bool) (/opt/llvm-mingw/bin/../lib/libLLVM.so.18.1+0x771c50)
#6 0x00007f07741a3c9d llvm::MCRegisterInfo::getCodeViewRegNum(llvm::MCRegister) const (/opt/llvm-mingw/bin/../lib/libLLVM.so.18.1+0x274ec9d)
#7 0x00007f0772f21c36 (/opt/llvm-mingw/bin/../lib/libLLVM.so.18.1+0x14ccc36)
#8 0x00007f0772f332a0 (/opt/llvm-mingw/bin/../lib/libLLVM.so.18.1+0x14de2a0)
#9 0x00007f0772f334be (/opt/llvm-mingw/bin/../lib/libLLVM.so.18.1+0x14de4be)
#10 0x00007f0772ea814c llvm::DebugHandlerBase::endFunction(llvm::MachineFunction const*) (/opt/llvm-mingw/bin/../lib/libLLVM.so.18.1+0x145314c)
#11 0x00007f0772e99e31 llvm::AsmPrinter::emitFunctionBody() (/opt/llvm-mingw/bin/../lib/libLLVM.so.18.1+0x1444e31)
#12 0x00007f0774dac69b (/opt/llvm-mingw/bin/../lib/libLLVM.so.18.1+0x335769b)
#13 0x00007f07727c64e0 (/opt/llvm-mingw/bin/../lib/libLLVM.so.18.1+0xd714e0)
#14 0x00007f077245624a llvm::FPPassManager::runOnFunction(llvm::Function&) (/opt/llvm-mingw/bin/../lib/libLLVM.so.18.1+0xa0124a)
#15 0x00007f07724563d4 llvm::FPPassManager::runOnModule(llvm::Module&) (/opt/llvm-mingw/bin/../lib/libLLVM.so.18.1+0xa013d4)
#16 0x00007f0772456e14 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/opt/llvm-mingw/bin/../lib/libLLVM.so.18.1+0xa01e14)
#17 0x00007f0778b6d802 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, llvm::Module*, clang::BackendAction, llvm::IntrusiveRefCntPtr<llvm::vfs::FileSystem>, std::unique_ptr<llvm::raw_pwrite_stream, std::default_delete<llvm::raw_pwrite_stream>>, clang::BackendConsumer*) (/opt/llvm-mingw/bin/../lib/libclang-cpp.so.18.1+0x1e81802)
#18 0x00007f0778ff0401 clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) (/opt/llvm-mingw/bin/../lib/libclang-cpp.so.18.1+0x2304401)
#19 0x00007f07777d1e79 clang::ParseAST(clang::Sema&, bool, bool) (/opt/llvm-mingw/bin/../lib/libclang-cpp.so.18.1+0xae5e79)
#20 0x00007f07799d11c1 clang::FrontendAction::Execute() (/opt/llvm-mingw/bin/../lib/libclang-cpp.so.18.1+0x2ce51c1)
#21 0x00007f07799497f9 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/opt/llvm-mingw/bin/../lib/libclang-cpp.so.18.1+0x2c5d7f9)
#22 0x00007f0779a5e4b3 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/opt/llvm-mingw/bin/../lib/libclang-cpp.so.18.1+0x2d724b3)
#23 0x00005573e2e3d373 cc1_main(llvm::ArrayRef<char const*>, char const*, void*) (/opt/llvm-mingw/bin/clang+0x14373)
#24 0x00005573e2e359dd (/opt/llvm-mingw/bin/clang+0xc9dd)
#25 0x00007f0779587a2d (/opt/llvm-mingw/bin/../lib/libclang-cpp.so.18.1+0x289ba2d)
#26 0x00007f07721b20c7 llvm::CrashRecoveryContext::RunSafely(llvm::function_ref<void ()>) (/opt/llvm-mingw/bin/../lib/libLLVM.so.18.1+0x75d0c7)
#27 0x00007f0779587dc7 (/opt/llvm-mingw/bin/../lib/libclang-cpp.so.18.1+0x289bdc7)
#28 0x00007f077954efa1 clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&, clang::driver::Command const*&, bool) const (/opt/llvm-mingw/bin/../lib/libclang-cpp.so.18.1+0x2862fa1)
#29 0x00007f077954fa5d clang::driver::Compilation::ExecuteJobs(clang::driver::JobList const&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*>>&, bool) const (/opt/llvm-mingw/bin/../lib/libclang-cpp.so.18.1+0x2863a5d)
#30 0x00007f07795627dc clang::driver::Driver::ExecuteCompilation(clang::driver::Compilation&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*>>&) (/opt/llvm-mingw/bin/../lib/libclang-cpp.so.18.1+0x28767dc)
#31 0x00005573e2e3a489 clang_main(int, char**, llvm::ToolContext const&) (/opt/llvm-mingw/bin/clang+0x11489)
#32 0x00005573e2e34dfb main (/opt/llvm-mingw/bin/clang+0xbdfb)
#33 0x00007f0771626d90 (/lib/x86_64-linux-gnu/libc.so.6+0x29d90)
#34 0x00007f0771626e40 __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x29e40)
#35 0x00005573e2e34e55 _start (/opt/llvm-mingw/bin/clang+0xbe55)
clang: error: clang frontend command failed with exit code 70 (use -v to see invocation)
clang version 18.1.4 (https://github.com/llvm/llvm-project.git e6c3289804a67ea0bb6a86fadbe454dd93b8d855)
Target: aarch64-w64-windows-gnu
Thread model: posix
InstalledDir: /opt/llvm-mingw/bin
clang: note: diagnostic msg:
********************
PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg: /tmp/reduced-9bcceb.c
clang: note: diagnostic msg: /tmp/reduced-9bcceb.sh
clang: note: diagnostic msg:
********************
reduced.c
#include <arm_neon_sve_bridge.h>
uint64_t aom_sum_squares_2d_i16_wxh_sve() {
svint64_t sum_squares = svdup_n_s64(0);
return svaddv_s64(svptrue_b64(), sum_squares);
}
(can also be reproduced by compiling aom 3.9.0 from source)
@llvm/issue-subscribers-backend-aarch64
Author: Kleis Auke Wolthuizen (kleisauke)
This also seems to affect SVE intrinsics on Arm64 (AArch64).
$ docker run --rm -v $(pwd):/repro -w /repro -it mstorsjo/llvm-mingw:latest aarch64-w64-mingw32-clang -march=armv8.2-a+sve -O1 -g -gcodeview -c reduced.c fatal error: error in backend: unknown codeview register Z0
Yep, although that error is about another unknown register, Z0
.
reduced.c
#include <arm_neon_sve_bridge.h> uint64_t aom_sum_squares_2d_i16_wxh_sve() { svint64_t sum_squares = svdup_n_s64(0); return svaddv_s64(svptrue_b64(), sum_squares); }
(can also be reproduced by compiling aom 3.9.0 from source)
FWIW, when not building in debug mode, there are other issues with trying to use SVE in libaom - see #80009. Microsoft haven't defined how to signal SVE registers when it comes to SEH unwind info, so it's impossible to write functions that back up/restore SVE registers (unless the unwind info is disabled). And anywhere a function signature uses SVE registers in arguments or return values, the functions need to back up/restore some such registers, iirc.
In my continuous build tests with libaom, I've had to use -DENABLE_SVE=0
since January, to work around #80009.
So essentially, any code with SVE instrinsics can't really be used for Windows targets. (Also, Microsoft haven't defined a flag for feature detection of SVE either, like PF_ARM_V82_DP_INSTRUCTIONS_AVAILABLE
for the aarch64 dotprod cpu extension.)
Thanks for the info! That also explains this error:
error: Incorrect size for av1_highbd_warp_affine_sve epilogue: 48 bytes of instructions in range, but .seh directives corresponding to 44 bytes
Yep, exactly. And even if you'd run Windows on SVE capable HW, I'm not sure if SVE actually would be available/usable, because iirc this is a feature that requires the OS to support it (e.g. backup/restore of the full SVE registers on context switch), and if not supported, it shouldn't be signaled as available.
And as long as the toolchains don't really support it, the only places it really works is if it is isolated within a function, not visible over function boundaries, no debug info to generate for it, etc. In practice, possible to use if you use it within a function, with assembly.
But anyway, as noted in https://github.com/llvm/llvm-project/issues/80009#issuecomment-1917899076, as the use of SVE becomes more widespread, we should probably look into making these errors more proper, pretty errors at a higher level, rather than trigger failed asserts and similar, as these don't very clearly show the user what actually is wrong and that this is, seemingly, an expected situation. CC @efriedma-quic
In any case, the discussion about SVE is better done in #80009, while this issue from the start was about missing codeview mappings for some NEON register setups, that should be supported in some way.
Repro
Tested with LLVM 17.0.0-rc1.
reduced.c
Additional info
Can also be reproduced by compiling either libwebp or aom from source.
Details
```Dockerfile # Build with: # docker build --build-arg ARCH=armv7 -t llvm-mingw . # docker run --rm llvm-mingw tar -cf - /packaging | tar -xvf - FROM mstorsjo/llvm-mingw:latest # Supported architectures: x86_64, i686, aarch64 and armv7 ARG ARCH=armv7 # Install git RUN apt-get update -qq && \ apt-get install -qqy --no-install-recommends git && \ apt-get clean -y && \ rm -rf /var/lib/apt/lists/* WORKDIR /build # Clone libwebp RUN git clone --depth 1 --recursive https://chromium.googlesource.com/webm/libwebp # Clone aom RUN git clone --depth 1 --recursive https://aomedia.googlesource.com/aom # Compiler flags ENV \ CFLAGS="-g -gcodeview" \ CXXFLAGS="-g -gcodeview" \ LDFLAGS="-Wl,--pdb=" WORKDIR /build/libwebp/build-$ARCH # Cross-compile libwebp for Windows RUN cmake \ -DCMAKE_BUILD_TYPE=Release \ -DCMAKE_INSTALL_PREFIX="/packaging" \ -DCMAKE_C_COMPILER=$ARCH-w64-mingw32-clang \ -DCMAKE_CXX_COMPILER=$ARCH-w64-mingw32-clang++ \ -DCMAKE_SYSTEM_NAME=Windows \ -DCMAKE_SYSTEM_PROCESSOR=$ARCH \ .. && \ cmake --build . -- -j$(nproc) && \ cmake --install . WORKDIR /build/aom/build-$ARCH # Cross-compile aom for Windows RUN cmake \ -DCMAKE_BUILD_TYPE=Release \ -DENABLE_DOCS=OFF \ -DENABLE_TESTDATA=OFF \ -DENABLE_TOOLS=OFF \ -DENABLE_EXAMPLES=OFF \ -DCONFIG_AV1_HIGHBITDEPTH=0 \ -DCONFIG_WEBM_IO=0 \ -DCONFIG_RUNTIME_CPU_DETECT=0 \ -DCMAKE_INSTALL_PREFIX="/packaging" \ -DCMAKE_C_COMPILER=$ARCH-w64-mingw32-clang \ -DCMAKE_CXX_COMPILER=$ARCH-w64-mingw32-clang++ \ -DCMAKE_SYSTEM_NAME=Windows \ -DCMAKE_SYSTEM_PROCESSOR=$ARCH \ .. && \ cmake --build . -- -j$(nproc) && \ cmake --install . ```/cc @mstorsjo