LLVM ERROR: Do not know how to split this operator's operand!

[TheEnbyperor]

When compiling the crate memchr version 2.2.0 with no_std I get this mysterious error. I have no idea what is causing this and enabling a backtrace does not produce any more output

 Running `rustc --crate-name memchr /home/q/.cargo/registry/src/github.com-1ecc6299db9ec823/memchr-2.2.0/src/lib.rs --color always --crate-type lib --emit=dep-info,metadata,link -C panic=abort -C debuginfo=2 -C metadata=6dc975c1ba1c008f -C extra-filename=-6dc975c1ba1c008f --out-dir /media/data/Users/BenjaminMisell/Documents/plan-rust/target/x86_64-none/debug/deps --target /media/data/Users/BenjaminMisell/Documents/plan-rust/x86_64-none.json -L dependency=/media/data/Users/BenjaminMisell/Documents/plan-rust/target/x86_64-none/debug/deps -L dependency=/media/data/Users/BenjaminMisell/Documents/plan-rust/target/debug/deps --cap-lints allow --sysroot /media/data/Users/BenjaminMisell/Documents/plan-rust/target/sysroot --cfg memchr_runtime_simd --cfg memchr_runtime_sse2 --cfg memchr_runtime_sse42 --cfg memchr_runtime_avx`
LLVM ERROR: Do not know how to split this operator's operand!

[nikic]

Can you run with --emit=llvm-ir and provide the .ll file?

[TheEnbyperor]

I've uploaded to my gdrive here https://drive.google.com/file/d/1fjzKcpAcA6w45pBLc89eE62RIIS2RLos/view?usp=sharing

[nikic]

Thanks! Reproduces on LLVM master with:

SplitVectorOperand Op #1: t35: i32 = llvm.x86.sse2.pmovmskb.128 TargetConstant:i64<6719>, t34, /home/q/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/../stdsimd/crates/core_arch/src/x86/sse2.rs:1401:4

LLVM ERROR: Do not know how to split this operator's operand!

[nikic]

Bugpoint reduced:

; ModuleID = 'reduced.ll'
source_filename = "memchr.53dfefha-cgu.0"
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-none"

define internal i32 @0(<2 x i64>*) unnamed_addr #0 {
  %2 = call i32 @llvm.x86.sse2.pmovmskb.128(<16 x i8> undef)
  ret i32 %2
}

; Function Attrs: nounwind readnone
declare i32 @llvm.x86.sse2.pmovmskb.128(<16 x i8>) unnamed_addr #1

attributes #0 = { "target-features"="-mmx,-sse,+soft-float,+sse2" }
attributes #1 = { nounwind readnone }

!llvm.module.flags = !{!0}

!0 = !{i32 2, !"Debug Info Version", i32 3}

The problem is the +soft-float target feature.

[TheEnbyperor]

Just to clarify is this is a bug in my target, rust, or LLVM. I can't use the CPUs floating point registers as this is code going in a kernel, so if soft-float is the issue are there any other options?

[nikic]

@TheEnbyperor It's technically a bug in LLVM. Just not sure how much interest there will be in supporting the rather peculiar combination of +soft-float and +sse2 on x86.

[TheEnbyperor]

Ah didn't see +sse2 in there. That's an error in my target, I didn't think it'd be enabled by default if -sse is in the target.

[Janrupf]

Hi, I want to add to this issue that this also happens using the x86_64-uefi-unknown target. Enabling sse fixes the issues. While my UEFI application still runs, I'm not sure if its a good idea.

However, in case anyone needs the new uefi target:

{
  "abi-return-struct-as-int": true,
  "allows-weak-linkage": false,
  "arch": "x86_64",
  "code-model": "large",
  "cpu": "x86-64",
  "data-layout": "e-m:w-i64:64-f80:128-n8:16:32:64-S128",
  "disable-redzone": true,
  "emit-debug-gdb-scripts": false,
  "env": "",
  "exe-suffix": ".efi",
  "executables": true,
  "features": "-mmx",
  "linker": "rust-lld",
  "linker-flavor": "lld-link",
  "lld-flavor": "link",
  "llvm-target": "x86_64-unknown-windows",
  "max-atomic-width": 64,
  "os": "uefi",
  "panic-strategy": "abort",
  "pre-link-args": {
    "lld-link": [
      "/NOLOGO",
      "/NXCOMPAT",
      "/nodefaultlib",
      "/entry:efi_main",
      "/subsystem:efi_application"
    ]
  },
  "singlethread": true,
  "stack-probes": true,
  "target-c-int-width": "32",
  "target-endian": "little",
  "target-pointer-width": "64",
  "vendor": "unknown"
}

[ethindp]

Getting this same error on Rustc 1.47.0 nightly. I can disable soft-float, but would I then need to implement x87 FPU exception handling? Because I have no idea how to do that.