LLVM produces SIGILL when enabling avx2 target feature on `x86_64-unknown-none`

[japaric]

Steps to reproduce

$ cargo new --lib repro
$ cd repro

$ echo '#![no_std]' > src/lib.rs
$ cargo add poly1305@0.8.0

$ rustup default 1.73.0
$ rustup target add x86_64-unknown-none
$ cargo b --target x86_64-unknown-none
error: could not compile `poly1305` (lib)

Caused by:
  process didn't exit successfully: `$RUSTUP_TOOLCHAIN/bin/rustc (..)` (signal: 4, SIGILL: illegal instruction)

Running gdb --args $RUSTC_INVOCATION_PRINTED_BY_CARGO produces this backtrace:

Stable Backtrace

Thread 7 "opt cgu.1" received signal SIGILL, Illegal instruction.
[Switching to Thread 0x7fffe11ff6c0 (LWP 102419)]
0x00007ffff13c939f in llvm::X86TargetLowering::ReplaceNodeResults(llvm::SDNode*, llvm::SmallVectorImpl<llvm::SDValue>&, llvm::SelectionDAG&) const [clone .cold.0] ()
   from /home/japaric/.rustup/toolchains/1.73.0-x86_64-unknown-linux-gnu/bin/../lib/../lib/libLLVM-17-rust-1.73.0-stable.so
(gdb) backtrace
#0  0x00007ffff13c939f in llvm::X86TargetLowering::ReplaceNodeResults(llvm::SDNode*, llvm::SmallVectorImpl<llvm::SDValue>&, llvm::SelectionDAG&) const [clone .cold.0] ()
   from /home/japaric/.rustup/toolchains/1.73.0-x86_64-unknown-linux-gnu/bin/../lib/../lib/libLLVM-17-rust-1.73.0-stable.so
#1  0x00007ffff1130ef5 in llvm::DAGTypeLegalizer::SplitVectorResult(llvm::SDNode*, unsigned int) [clone .cold.0] () from /home/japaric/.rustup/toolchains/1.73.0-x86_64-unknown-linux-gnu/bin/../lib/../lib/libLLVM-17-rust-1.73.0-stable.so
#2  0x00007ffff000d41a in llvm::DAGTypeLegalizer::run() () from /home/japaric/.rustup/toolchains/1.73.0-x86_64-unknown-linux-gnu/bin/../lib/../lib/libLLVM-17-rust-1.73.0-stable.so
#3  0x00007ffff01ff81a in llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator<llvm::ilist_detail::node_options<llvm::Instruction, false, false, void>, false, true>, llvm::ilist_iterator<llvm::ilist_detail::node_options<llvm::Instruction, false, false, void>, false, true>, bool&) () from /home/japaric/.rustup/toolchains/1.73.0-x86_64-unknown-linux-gnu/bin/../lib/../lib/libLLVM-17-rust-1.73.0-stable.so
#4  0x00007ffff04ff282 in llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) () from /home/japaric/.rustup/toolchains/1.73.0-x86_64-unknown-linux-gnu/bin/../lib/../lib/libLLVM-17-rust-1.73.0-stable.so
#5  0x00007ffff034fc0a in llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) () from /home/japaric/.rustup/toolchains/1.73.0-x86_64-unknown-linux-gnu/bin/../lib/../lib/libLLVM-17-rust-1.73.0-stable.so
#6  0x00007ffff034f4ee in (anonymous namespace)::X86DAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&) [clone .llvm.6232165262612102610] () from /home/japaric/.rustup/toolchains/1.73.0-x86_64-unknown-linux-gnu/bin/../lib/../lib/libLLVM-17-rust-1.73.0-stable.so
#7  0x00007ffff016d66a in llvm::FPPassManager::runOnModule(llvm::Module&) () from /home/japaric/.rustup/toolchains/1.73.0-x86_64-unknown-linux-gnu/bin/../lib/../lib/libLLVM-17-rust-1.73.0-stable.so
#8  0x00007ffff05dcaac in llvm::legacy::PassManagerImpl::run(llvm::Module&) () from /home/japaric/.rustup/toolchains/1.73.0-x86_64-unknown-linux-gnu/bin/../lib/../lib/libLLVM-17-rust-1.73.0-stable.so
#9  0x00007ffff64d36a6 in LLVMRustWriteOutputFile () from /home/japaric/.rustup/toolchains/1.73.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-453cf35e1dd187fa.so
#10 0x00007ffff64d2558 in rustc_codegen_llvm[13e834ec38ef84a5]::back::write::write_output_file () from /home/japaric/.rustup/toolchains/1.73.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-453cf35e1dd187fa.so
#11 0x00007ffff64cfcd4 in rustc_codegen_llvm[13e834ec38ef84a5]::back::write::codegen () from /home/japaric/.rustup/toolchains/1.73.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-453cf35e1dd187fa.so
#12 0x00007ffff64cd074 in rustc_codegen_ssa[1239057ba2d16fcb]::back::write::finish_intra_module_work::<rustc_codegen_llvm[13e834ec38ef84a5]::LlvmCodegenBackend> () from /home/japaric/.rustup/toolchains/1.73.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-453cf35e1dd187fa.so
#13 0x00007ffff64cc75d in rustc_codegen_ssa[1239057ba2d16fcb]::back::write::execute_optimize_work_item::<rustc_codegen_llvm[13e834ec38ef84a5]::LlvmCodegenBackend> () from /home/japaric/.rustup/toolchains/1.73.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-453cf35e1dd187fa.so
#14 0x00007ffff64ca627 in std[3759e478f3a6c4f2]::sys_common::backtrace::__rust_begin_short_backtrace::<<rustc_codegen_llvm[13e834ec38ef84a5]::LlvmCodegenBackend as rustc_codegen_ssa[1239057ba2d16fcb]::traits::backend::ExtraBackendMethods>::spawn_named_thread<rustc_codegen_ssa[1239057ba2d16fcb]::back::write::spawn_work<rustc_codegen_llvm[13e834ec38ef84a5]::LlvmCodegenBackend>::{closure#0}, ()>::{closure#0}, ()> () from /home/japaric/.rustup/toolchains/1.73.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-453cf35e1dd187fa.so
#15 0x00007ffff6459256 in <<std[3759e478f3a6c4f2]::thread::Builder>::spawn_unchecked_<<rustc_codegen_llvm[13e834ec38ef84a5]::LlvmCodegenBackend as rustc_codegen_ssa[1239057ba2d16fcb]::traits::backend::ExtraBackendMethods>::spawn_named_thread<rustc_codegen_ssa[1239057ba2d16fcb]::back::write::spawn_work<rustc_codegen_llvm[13e834ec38ef84a5]::LlvmCodegenBackend>::{closure#0}, ()>::{closure#0}, ()>::{closure#1} as core[d28c4e8d9c4eebaa]::ops::function::FnOnce<()>>::call_once::{shim:vtable#0} ()
   from /home/japaric/.rustup/toolchains/1.73.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-453cf35e1dd187fa.so
#16 0x00007ffff3d71295 in alloc::boxed::{impl#47}::call_once<(), dyn core::ops::function::FnOnce<(), Output=()>, alloc::alloc::Global> () at library/alloc/src/boxed.rs:2007
#17 alloc::boxed::{impl#47}::call_once<(), alloc::boxed::Box<dyn core::ops::function::FnOnce<(), Output=()>, alloc::alloc::Global>, alloc::alloc::Global> () at library/alloc/src/boxed.rs:2007
#18 std::sys::unix::thread::{impl#2}::new::thread_start () at library/std/src/sys/unix/thread.rs:108
#19 0x00007ffff3ae59eb in ?? () from /usr/lib/libc.so.6
#20 0x00007ffff3b697cc in ?? () from /usr/lib/libc.so.6

---

Using nightly-2023-11-15 toolchain produces a "LLVM ERROR" instead:

$ cargo +nightly-2023-11-15 b --target x86_64-unknown-none
LLVM ERROR: Do not know how to split the result of this operator!

error: could not compile `poly1305` (lib)

Unless the --release flag is used, then you get the SIGILL with the nightly toolchain. The backtrace appears to be similar to the stable toolchain one:

Nightly Backtrace

(gdb) backtrace
#0  0x00007ffff12744ca in llvm::X86TargetLowering::ReplaceNodeResults(llvm::SDNode*, llvm::SmallVectorImpl<llvm::SDValue>&, llvm::SelectionDAG&) const [clone .cold.0] ()
   from /home/japaric/.rustup/toolchains/nightly-2023-11-15-x86_64-unknown-linux-gnu/bin/../lib/../lib/libLLVM-17-rust-1.76.0-nightly.so
#1  0x00007ffff133a1ce in llvm::DAGTypeLegalizer::SplitVectorResult(llvm::SDNode*, unsigned int) [clone .cold.0] () from /home/japaric/.rustup/toolchains/nightly-2023-11-15-x86_64-unknown-linux-gnu/bin/../lib/../lib/libLLVM-17-rust-1.76.0-nightly.so
#2  0x00007ffff020e085 in llvm::DAGTypeLegalizer::run() () from /home/japaric/.rustup/toolchains/nightly-2023-11-15-x86_64-unknown-linux-gnu/bin/../lib/../lib/libLLVM-17-rust-1.76.0-nightly.so
#3  0x00007ffff03a8ada in llvm::SelectionDAGISel::CodeGenAndEmitDAG() () from /home/japaric/.rustup/toolchains/nightly-2023-11-15-x86_64-unknown-linux-gnu/bin/../lib/../lib/libLLVM-17-rust-1.76.0-nightly.so
#4  0x00007ffff09c09b8 in llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) () from /home/japaric/.rustup/toolchains/nightly-2023-11-15-x86_64-unknown-linux-gnu/bin/../lib/../lib/libLLVM-17-rust-1.76.0-nightly.so
#5  0x00007ffff05f27fa in llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) () from /home/japaric/.rustup/toolchains/nightly-2023-11-15-x86_64-unknown-linux-gnu/bin/../lib/../lib/libLLVM-17-rust-1.76.0-nightly.so
#6  0x00007ffff05f2016 in (anonymous namespace)::X86DAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&) [clone .llvm.4022770523405222600] () from /home/japaric/.rustup/toolchains/nightly-2023-11-15-x86_64-unknown-linux-gnu/bin/../lib/../lib/libLLVM-17-rust-1.76.0-nightly.so
#7  0x00007ffff034e3c1 in llvm::FPPassManager::runOnFunction(llvm::Function&) () from /home/japaric/.rustup/toolchains/nightly-2023-11-15-x86_64-unknown-linux-gnu/bin/../lib/../lib/libLLVM-17-rust-1.76.0-nightly.so
#8  0x00007ffff034d947 in llvm::FPPassManager::runOnModule(llvm::Module&) () from /home/japaric/.rustup/toolchains/nightly-2023-11-15-x86_64-unknown-linux-gnu/bin/../lib/../lib/libLLVM-17-rust-1.76.0-nightly.so
#9  0x00007ffff04e317a in llvm::legacy::PassManagerImpl::run(llvm::Module&) () from /home/japaric/.rustup/toolchains/nightly-2023-11-15-x86_64-unknown-linux-gnu/bin/../lib/../lib/libLLVM-17-rust-1.76.0-nightly.so
#10 0x00007ffff6b745d0 in LLVMRustWriteOutputFile () from /home/japaric/.rustup/toolchains/nightly-2023-11-15-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-a2929300a34289e9.so
#11 0x00007ffff6b7420c in rustc_codegen_llvm[e0f834ca461547f0]::back::write::write_output_file () from /home/japaric/.rustup/toolchains/nightly-2023-11-15-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-a2929300a34289e9.so
#12 0x00007ffff6b71bdf in rustc_codegen_llvm[e0f834ca461547f0]::back::write::codegen () from /home/japaric/.rustup/toolchains/nightly-2023-11-15-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-a2929300a34289e9.so
#13 0x00007ffff6b7187f in rustc_codegen_ssa[130828829af41105]::back::write::finish_intra_module_work::<rustc_codegen_llvm[e0f834ca461547f0]::LlvmCodegenBackend> ()
   from /home/japaric/.rustup/toolchains/nightly-2023-11-15-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-a2929300a34289e9.so
#14 0x00007ffff6ccb32b in std[14019a58b7d275f1]::sys_common::backtrace::__rust_begin_short_backtrace::<<rustc_codegen_llvm[e0f834ca461547f0]::LlvmCodegenBackend as rustc_codegen_ssa[130828829af41105]::traits::backend::ExtraBackendMethods>::spawn_named_thread<rustc_codegen_ssa[130828829af41105]::back::write::spawn_work<rustc_codegen_llvm[e0f834ca461547f0]::LlvmCodegenBackend>::{closure#0}, ()>::{closure#0}, ()> () from /home/japaric/.rustup/toolchains/nightly-2023-11-15-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-a2929300a34289e9.so
#15 0x00007ffff6cca7e4 in <<std[14019a58b7d275f1]::thread::Builder>::spawn_unchecked_<<rustc_codegen_llvm[e0f834ca461547f0]::LlvmCodegenBackend as rustc_codegen_ssa[130828829af41105]::traits::backend::ExtraBackendMethods>::spawn_named_thread<rustc_codegen_ssa[130828829af41105]::back::write::spawn_work<rustc_codegen_llvm[e0f834ca461547f0]::LlvmCodegenBackend>::{closure#0}, ()>::{closure#0}, ()>::{closure#1} as core[a62a0f03b43184e2]::ops::function::FnOnce<()>>::call_once::{shim:vtable#0} ()
   from /home/japaric/.rustup/toolchains/nightly-2023-11-15-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-a2929300a34289e9.so
#16 0x00007ffff1f98915 in alloc::boxed::{impl#47}::call_once<(), dyn core::ops::function::FnOnce<(), Output=()>, alloc::alloc::Global> () at library/alloc/src/boxed.rs:2007
#17 alloc::boxed::{impl#47}::call_once<(), alloc::boxed::Box<dyn core::ops::function::FnOnce<(), Output=()>, alloc::alloc::Global>, alloc::alloc::Global> () at library/alloc/src/boxed.rs:2007
#18 std::sys::unix::thread::{impl#2}::new::thread_start () at library/std/src/sys/unix/thread.rs:108
#19 0x00007ffff1d899eb in ?? () from /usr/lib/libc.so.6
#20 0x00007ffff1e0d7cc in ?? () from /usr/lib/libc.so.6

Meta

Downstream discussion: RustCrypto/universal-hashes#189

rustc +1.73.0 --version --verbose

rustc 1.73.0 (cc66ad468 2023-10-03)
binary: rustc
commit-hash: cc66ad468955717ab92600c770da8c1601a4ff33
commit-date: 2023-10-03
host: x86_64-unknown-linux-gnu
release: 1.73.0
LLVM version: 17.0.2

rustc +nightly-2023-11-15 --version --verbose

rustc 1.76.0-nightly (dd430bc8c 2023-11-14)
binary: rustc
commit-hash: dd430bc8c22f57992ec1457a87437d14283fdd65
commit-date: 2023-11-14
host: x86_64-unknown-linux-gnu
release: 1.76.0-nightly
LLVM version: 17.0.5

[nikic]

With assertions:

SplitVectorResult #0: t41: v8i32 = llvm.x86.avx2.psllv.d.256 TargetConstant:i64<12153>, t28, t39, /rustc/dd430bc8c22f57992ec1457a87437d14283fdd65/library/core/src/../../stdarch/crates/core_arch/src/x86/avx2.rs:2718:15

[nikic]

@llvm.x86.avx2.psllv.d.256 is called inside @_ZN4core9core_arch3x864avx217_mm256_sllv_epi3217ha2b3f3fbfaa54a1bE with these attributes:

attributes #3 = { inlinehint noredzone nounwind nonlazybind "probe-stack"="inline-asm" "target-cpu"="x86-64" "target-features"="-mmx,-sse,-sse2,-sse3,-ssse3,-sse4.1,-sse4.2,-3dnow,-3dnowa,-avx,-avx2,+soft-float,+avx2" }

The combination of +soft-float and +avx2 is not supported. rustc probably needs to explicitly remove that target feature when compiling functions that enabled FP target features.

[newpavlov]

@nikic
The code in question uses autodetection, so it has two branches: "soft" and SIMD-based. Autodetection is done using the cpufeatures crate. On targets like x86_64-unknown-none we effectively get the following code:

#[target_feature(enable = "avx2")]
unsafe fn simd_fn() { ... }

if false {
   unsafe { simd_fn() }
} else {
    soft_fn();
}

The idea here is that the first branch should be eliminated by compiler. But it looks like the compiler starts compiling and lowering simd_fn before branch elimination takes place, which triggers SIGILL with enabled soft floats.

[Noratrieb]

The compiler doesn't eliminate branches like these in debug mode right now (which, while it does cause perf problems sometimes, is not a bug).

[newpavlov]

Yes, but note that the SIGILL happens with --release. In debug mode it's fine (though far from ideal) to get "LLVM ERROR: Do not know how to split the result of this operator!".

[nikic]

I checked, and the --release build failure comes down to essentially the same thing. It's still due to functions with +soft-float,+avx2 target features, just catching a different assertion.

[newpavlov]

Can Rust remove +soft-float inherited from target definition for code which explicitly enables FP-dependent target features?

[nikic]

That should be possible, with two caveats:

• This may change the ABI of scalar floats passed to the function -- something we currently don't force indirect passing for, unlike vectors.
• There may be a danger that this results in the generation of libcalls that will fail to link on a +soft-float target.

cc @RalfJung I'm sure you will appreciate this new bit of target feature fun.

[newpavlov]

As noted in the linked RustCrypto issue, ideally we need something like this to properly handle nastiness like this in libraries. But I guess it's a separate discussion.

[RalfJung]

I'd say compiling SIMD code on a softfloat target makes fairly little sense. Maybe we should have cfg(hardfloat) so that these functions can be entirely removed on softfloat targets?

Letting you disable target features in a function wouldn't really help, we'd still want to reject even declaring such a function since its ABI is all wrong. (Or we'd have to get LLVM to support a softfloat ABI for SIMD types I guess.) See rust-lang/lang-team#235 for more details on the ABI issues surrounding target features.

We definitely do not want to support soft-float in target_feature, neither positively nor negatively, due to its ABI impact. Soft-float vs hard-float is a target-wide decision that can't be altered on a per-function or even per-compilation-unit level. We currently accept some nonsense like -Ctarget-features=+soft-float on our hardfloat target but that's completely unsupported and pretty broken (you can cause UB in safe code due to ABI incompatibility), IMO we should reject such flags.

[newpavlov]

Maybe we should have cfg(hardfloat) so that these functions can be entirely removed on softfloat targets?

Yes, it could work, but I think a more fundamental solution would be a proper support of "negative" target features. Arguably, we should consider the relation between hard floats and SIMD instructions nothing more than an implementation detail of the x86 targets.

Another alternative is to replace SIMD functions (i.e. functions marked with #[target_feature(enable = "..")]) with placeholders on soft-float targets. The placeholders may panic, abort, or even be something like unreachable_unchecked. SIMD functions should not be reachable on soft-float targets in the first place, so, since calling them is UB, such replacement should be legal for compiler.