Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
TheEnbyperor opened this issue Jun 10, 2019 · 14 comments
Closed

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

TheEnbyperor opened this issue Jun 10, 2019 · 14 comments
Labels
A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. A-simd Area: SIMD (Single Instruction Multiple Data) C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@TheEnbyperor
Copy link

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!
@jonas-schievink jonas-schievink added A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. A-simd Area: SIMD (Single Instruction Multiple Data) C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jun 10, 2019
@nikic
Copy link
Contributor

nikic commented Jun 10, 2019

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

@TheEnbyperor
Copy link
Author

@nikic
Copy link
Contributor

nikic commented Jun 10, 2019

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
Copy link
Contributor

nikic commented Jun 10, 2019

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
Copy link
Author

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
Copy link
Contributor

nikic commented Jun 11, 2019

@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
Copy link
Author

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
Copy link

Janrupf commented Sep 7, 2019

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
Copy link

ethindp commented Aug 15, 2020

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.

@DianaNites
Copy link

DianaNites commented Aug 22, 2020

Also getting this on the current nightly, rustc 1.47.0-nightly (e15510ca3 2020-08-20).

Minimal reproduction

Memchr 2.2 and up don't compile on the x86_64-unknown-uefi target using the latest nightly, currently rustc 1.47.0-nightly (e15510ca3 2020-08-20), with "LLVM ERROR: Do not know how to split this operator's operand!"

memchr 2.1 and below compile, however.

If memchr is in your dependency tree, a workaround is to add memchr = { version = "=2.1", default-features = false } to your Cargo.toml, causing cargo to resolve to that specific version for the entire dependency tree, if possible.

@pitust
Copy link

pitust commented Nov 11, 2020

fixed it in my operating system by enabling SSE (feature and hardware support). In my case the culprit is (i think) fontdue, but who knows.

@DianaNites
Copy link

DianaNites commented Nov 11, 2020

Memchr seems to have silently and unexpectedly fixed it in BurntSushi/memchr#77, on crates.io as 2.3.4!

For other crates with this issue they should be able to take a similar approach to memchr's solution, and it also doesn't seem to be a Rust bug, though perhaps problems like this could be detected and a better error message produced?

@workingjubilee
Copy link
Member

I suspect the only really viable solution on the Rust end is to require soft-float XOR x87/sse/sse2, and it's not clear that is desirable. This issue seems to have served its purpose, so closing. Please feel free to reopen and continue if this remains a concern.

@kennystrawnmusic
Copy link

Getting a similar result when attempting to compile rand_chacha for the x86_64-unknown-uefi target. Only reproducible on the latest version of such though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. A-simd Area: SIMD (Single Instruction Multiple Data) C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

9 participants