LLVM ERROR: Do not know how to split the result of this operator!

[glandium]

There is a family of errors related to splitting that happen when building Firefox for android. I haven't managed to get a usefully reduced testcase. The gist of it is that it involves -Clinker-plugin-lto and linking being done outside cargo, between C/C++ and rust code with the i686-linux-android or x86_64-linux-android targets. The former fails with LLVM ERROR: Do not know how to split the result of this operator!, and the latter with LLVM ERROR: Cannot select: 0x7fa32221e808: v16i8 = X86ISD::PSHUFB 0x7fa323d69d40, 0x7fa2ca5946d8, /rustc/d9aa28767287670df6cf823b94629122e04442c0/library/core/src/../../stdarch/crates/core_arch/src/x86/ssse3.rs:80:15 (...), and seems to be related to the lack of target-features in the LLVM-IR emitted by rust (that is, building my own rustc with this condition changed to true fixes the issue).

It seems to me rustc should always emit target-features, especially when using -Clinker-plugin-lto, where the LLVM that will read the LLVM bytecode doesn't necessarily have the same target definitions that rustc has.

This is how this can be reproduced:

• hg clone https://hg.mozilla.org/mozilla-unified or git clone https://github.com/mozilla/gecko-dev
• cd mozilla-unified or cd gecko-dev
• mkdir ~/.mozbuild
• ./mach --no-interactive bootstrap --application-choice mobile_android (this might fail to install openjdk-8-jdk-headless depending on your distro, you might need to find and install it yourself, and try again)
• Restart your shell and return in the mozilla-unified or gecko-dev directory.
• Edit mozconfig to uncomment ac_add_options --target=i686 and add ac_add_options MOZ_LTO=cross
• Run rustup target add i686-linux-android
• ./mach build

[jfrimmel]

Maybe we should do something like that?

if !function_features.is_empty() {
if !matches_llvm_defaults(function_features) {

Where matches_llvm_defaults checks, whether or nut rustc and LLVM have the same target definitions.

[glandium]

You'd want that against global_features, presumably, but that would still consider the defaults in rustc's LLVM, not the final LLVM, which could just as well be a newer or older version with different defaults (or alternatively, a patched version).

[hkratz]

Makes sense IMHO, clang does it too: https://godbolt.org/z/PjGbWjxY3

[hkratz]

@rustbot label +A-LTO +A-LLVM

[glandium]

Oh yeah, anything that you add to --target-features on the rustc command line is unknown to the final linker. They would only appear if the function has #[target_feature(enable=...)] (which is what the condition I pointed at is for).
Interestingly, the code that adds the target-features to the IR "only" then adds the combination of what #[target_feature] added, along the command line, and base.features from the rustc target description. So even with the condition removed, we wouldn't get the same behavior as clang (for instance, the x86_64-unknown-linux-gnu has an empty base.features).