LLVM assertion when using `i128` with the NVPTX

[japaric]

This effectively means you can't compile core for these targets.

STR

$ edit foo.rs && cat $_

#![crate_type = "lib"]
#![feature(i128_type)]
#![feature(lang_items)]
#![feature(no_core)]
#![no_core]

fn foo() -> i128 { 0 }

#[lang = "copy"]
trait Copy {}

#[lang = "sized"]
trait Sized {}

$ edit nvptx64-nvidia-cuda.json && cat $_

{
  "arch": "nvptx64",
  "cpu": "sm_20",
  "data-layout": "e-i64:64-v16:16-v32:32-n16:32:64",
  "llvm-target": "nvptx64-nvidia-cuda",
  "max-atomic-width": 0,
  "os": "cuda",
  "panic-strategy": "abort",
  "target-endian": "little",
  "target-pointer-width": "64"
}

$ rustc --target nvptx64-nvidia-cuda foo.rs
rustc: /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/llvm/lib/Target/NVPTX/NVPTXISelLowering.cpp:2492: virtual llvm::SDValue llvm::NVPTXTargetLowering::LowerReturn(llvm::SDValue, llvm::CallingConv::ID, bool, const llvm::SmallVectorImpl<llvm::ISD::OutputArg>&, const llvm::SmallVectorImpl<llvm::SDValue>&, const llvm::SDLoc&, llvm::SelectionDAG&) const: Assertion `ValVTs.size() == OutVals.size() && "Bad return value decomposition"' failed.

Meta

$ rustc -V
rustc 1.16.0-nightly (468227129 2017-01-03)

---

Already Fixed

$ cat msp430.json && cat $_

{
  "arch": "msp430",
  "asm-args": ["-mcpu=msp430"],
  "data-layout": "e-m:e-p:16:16-i32:16:32-a:16-n8:16",
  "executables": true,
  "linker": "msp430-elf-gcc",
  "llvm-target": "msp430",
  "max-atomic-width": 0,
  "no-integrated-as": true,
  "os": "none",
  "panic-strategy": "abort",
  "relocation-model": "static",
  "target-endian": "little",
  "target-pointer-width": "16",
  "vendor": "unknown"
}

$ rustc --target msp430 foo.rs
Return operand #4 has unhandled type i16
UNREACHABLE executed at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/llvm/lib/CodeGen/CallingConvLower.cpp:114!

[japaric]

This may have been caused by the i128 PR ( #38482 ). No LLVM assertion is raised if I compile core with --cfg stage0, which removes the i128 stuff.

We could try to fix this or we could cfg away the i128 stuff for the nvptx targets in the meantine. The LLVM assertions render the NVPTX backend unusable in the nightlies.

cc @est31 @nagisa Have you seen any LLVM assertion like the ones above while working on implementing i128?
cc @alexcrichton cfg?

[est31]

@japaric no, I can't remember seeing such an assertion. It seems to be in PTX related code. but its very likely that i128 broke some of the non tier1 platforms. You can only tell whether they break once they actually do :/

Can you try to generate a minimum reproducible example? Then we might know more...

[japaric]

Seems like the msp430 target broke too:

$ rustc --target msp430 $(rustc --print sysroot)/lib/rustlib/src/rust/src/libcore/lib.rs --emit=asm
Call result #4 has unhandled type i16
UNREACHABLE executed at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/llvm/lib/CodeGen/CallingConvLower.cpp:167!

with

{
  "arch": "msp430",
  "asm-args": ["-mcpu=msp430"],
  "data-layout": "e-m:e-p:16:16-i32:16:32-a:16-n8:16",
  "executables": true,
  "linker": "msp430-elf-gcc",
  "llvm-target": "msp430",
  "max-atomic-width": 0,
  "no-integrated-as": true,
  "os": "none",
  "panic-strategy": "abort",
  "relocation-model": "static",
  "target-endian": "little",
  "target-pointer-width": "16",
  "vendor": "unknown"
}

Using --cfg stage0 works fine.

cc @pftbest

[japaric]

@est31 Examples

#![crate_type = "lib"]
#![feature(i128_type)]
#![feature(lang_items)]
#![feature(no_core)]
#![no_core]

fn foo() -> i128 {
    0
}

#[lang = "copy"]
trait Copy {}

#[lang = "sized"]
trait Sized {}

$ rustc --target nvptx64-nvidia-cuda foo.rs
rustc: /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/llvm/lib/Target/NVPTX/NVPTXISelLowering.cpp:2492: virtualllvm::SDValue llvm::NVPTXTargetLowering::LowerReturn(llvm::SDValue, llvm::CallingConv::ID, bool, const llvm::SmallVectorImpl<llvm::ISD::OutputArg>&, const llvm::SmallVectorImpl<llvm::SDValue>&, const llvm::SDLoc&, llvm::SelectionDAG&) const: Assertion `ValVTs.size() == OutVals.size() && "Bad return value decomposition"' failed.

$ rustc --target msp430 foo.rs
Return operand #4 has unhandled type i16
UNREACHABLE executed at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/llvm/lib/CodeGen/CallingConvLower.cpp:114!

---

#![crate_type = "lib"]
#![feature(i128_type)]
#![feature(lang_items)]
#![feature(no_core)]
#![no_core]

fn foo(x: i128) {}

#[lang = "copy"]
trait Copy {}

#[lang = "sized"]
trait Sized {}

$ rustc --target nvptx64-nvidia-cuda foo.rs
rustc: /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp:7952: void llvm::SelectionDAGISel::LowerArguments(const llvm::Function&): Assertion `InVals.size() == Ins.size() && "LowerFormalArguments didn't emit the correct number of values!"' failed.

[pftbest]

msp430 EABI doesn't specify how to return 128 bit values, and LLVM does not support them on msp430, so I don't see an easy fix for this.

[alexcrichton]

These are tier 3 platforms, so basically anything goes IMO in terms of language guarantees. If they don't support i128 at a fundamental level then it seems like if we want them to compile we'll have to cfg out support.

[japaric]

I'm trying to understand this better:

• If the ABI does not specify how 128-bit values are passed/returned, does that mean that the architecture doesn't support 128-bit values at the fundamental level?

• Do all the ABIs of the all the other platform 2 targets (x86, ARM, MIPS, PowerPC, SystemZ) specify how 128-bit values are returned?

• (What about wasm and asm.js? Do those even have an ABI? How does the 128-bit stuff even works there?)

I'm wondering if we should:

• Add a supports_i128 field to target specifications. For targets that don't support i128 at the fundamental level.

• Or, maybe add Cargo feature to core to cfg away the i128 stuff.

• Or unilateraly cfg away i128 in core for nvptx and msp430.

I personally don't like either option. To me this seems like a limitation in what LLVM can do today but that can be fixed in the future.

Also, if we had pure MIR rlibs this wouldn't be a problem at all because the i128 stuff would never be passed to LLVM if it wasn't being used by the final application.

To sum it up, I'm not sure what to do here ...

[pftbest]

If the ABI does not specify how 128-bit values are passed/returned, does that mean that the architecture doesn't support 128-bit values at the fundamental level?

Right now on MSP430 values from the functions are returned using 4 16bit registers r12-r15. So in total you can return only 64 bits of data. There is an exception though, for returning large structs, the data is placed on the stack and reference is placed in the registers. So I guess it will be possible to bodge some hack that will treat i128 like a struct, but I don't know if anyone tried to implement 128 bit values on 16bit cpu, so it will be a new territory and potentially a lot of work for a feature that may not be useful at all on a small MCU.

[japaric]

@pftbest yeah, but if LLVM can generate code for a function that returns [u8; 16] then it should be able to use the same trick to return an i128. It's just that noboby has taught it how to do that. (i128 ops are totally different though but at least LLVM should emit intrinsics instead of raising assertions)

I don't know if anyone tried to implement 128 bit values on 16bit cpu

How about i128 on 8-bit AVR? 😄