128 bit integers not supported (needed for Rust)

[est31]

Hi!

Rust recently has gained experimental 128 bit integer support. The intention is to, unlike C or C++ which only support it on X86_64, provide 128 bit integers cross platform, just like its done for 64 bit integers already.

The regression test for 128 bit integers in the rust codebase is currently ignored for emscripten. When unignoring it, one gets the error message:

LLVM ERROR: Function _ZN4test9black_box17h6220793b9183d295E has illegal integer argument

This error message originates in code from this repo. The file that contains the error message also states that 64 is the maximum supported number. It would be great if it could be raised to 128.

This is a fairly minimal reproducing example:

#![feature(i128_type, test)]

#[inline(never)]
fn b(i: i128) -> i128 { // same as the black_box function from the test crate
    i
}

fn main() {
    let x: i128 = b(-1);
    let y: i128 = b(3);
    assert_eq!(0, !x);
}

cc @nagisa
cc @alexcrichton

[kripken]

How does this work in a regular rust build? Does it just rely on LLVM's legalization to lower the i128s?

[est31]

I'm not familiar enough with LLVM to know what you mean by legalization but it does rely on the backend to handle i128. Essentially, it translates Rust's i128 to LLVM IR i128. For example, the backend would get a LLVM IR like this for an identity function like b above:

define internal i128 @_ZN10playground3foo17hd7093dc3f2d7bbe8E(i128) unnamed_addr #3 !dbg !227 {
entry-block:
  %f = alloca i128
  %arg0 = alloca i128
  store i128 %0, i128* %arg0
  call void @llvm.dbg.declare(metadata i128* %arg0, metadata !230, metadata !137), !dbg !231
  call void @llvm.dbg.declare(metadata i128* %f, metadata !232, metadata !137), !dbg !234
  br label %start, !dbg !234

start:                                            ; preds = %entry-block
  %1 = load i128, i128* %arg0, !dbg !235
  store i128 %1, i128* %f, !dbg !235
  %2 = load i128, i128* %f, !dbg !234
  ret i128 %2, !dbg !234
}

[kripken]

I see, thanks. Well, this is something that can't easily be supported in fastcomp. The LLVM backend can handle it, though, so this might just wait for that to be ready (unless someone is interested to improve fastcomp legalization)

[marmistrz]

Since llvm backend has now become the default, this is probably a wontfix, isn't it?

[kripken]

Thanks @marmistrz , yeah, since we use the llvm backend this is no longer a problem.

[est31]

Yeah I'd say it was fixed by rust-lang/rust@2bf59be