Incorrect values from float::signum() when using JIT

[jedestep]

This initially showed up in rusti, but compilation with JIT causes issues as well. Given the following program

fn main() {
    let f: f64 = -50 as f64;
    println(a.signum().to_str());
}

$ rustc -Z jit signum.rs
1

This does not occur when compiling with LLVM. My OS is OSX 10.8 and my architecture is x86-64.

[alexcrichton]

Oh turns out I didn't fix it with that commit. So here's some more investigation (assuming your file is called foo.rs). This was done after #7125 is applied, which removes force-running particular optimizations (independent of what's specified otherwise, allowing a more controlled environment).

With no optimizations, the JIT code runs just fine

$ ./x86_64-apple-darwin/stage2/bin/rustc -Z jit ./foo.rs       
-1

With run with optimizations, the code doesn't pass

$ ./x86_64-apple-darwin/stage2/bin/rustc -Z jit -O ./foo.rs       
1

With run with some optimizations, the code doesn't pass differently

$ ./x86_64-apple-darwin/stage2/bin/rustc -Z jit --passes instcombine,scalarrepl-ssa ./foo.rs       
NaN

@Aatch, you recently did some work with LLVM passes, right? Do you know if these passes could combine to create different code? Also, I'm not sure if LLVM has a pass to dump the module, but it'd be awesome to be able to dump the LLVM bytecode between each pass (by the way, it's awesome just specifying the passes on the command line!).

If we keep the optimizations, we're probably generating code that LLVM isn't expecting, so it's optimizing it away from what we want. Why it's only doing this in the JIT though is a bit baffling...

[alexcrichton]

Oh, found the print-module pass, it's just not under --passes list

[alexcrichton]

OK, I don't think this is a problem with optimizations at all:

$ cat foo.rs
#[inline(never)]
fn baz(f: f64) -> f64 {
    f.signum()
}
#[inline(never)]
fn bar() {
    let f: f64 = -50 as f64;
    foo(baz(f))
}

fn main() {
    bar();
}

#[inline(never)]
fn foo<T>(t: T) {
    println(fmt!("%?", t));
}
$ ./x86_64-apple-darwin/stage2/bin/rustc -Z jit ./foo.rs
-1
$ ./x86_64-apple-darwin/stage2/bin/rustc -Z jit --passes print-module ./foo.rs 2> /dev/null
1

Basically on that code if you run any pass, it returns the wrong result. Now running with -O still runs the always-inline pass, so this would imply that when the always-inline pass isn't run, the code produces the wrong result. However I tried a few permutations on the code above and always-inline,instcombine produces NaN.

Again though, this only shows up when using the JIT.

[alexcrichton]

And with yet another round of lots and lots of compiling, I conclude this is blocked on #7115

[Aatch]

@alexcrichton The JIT backend (especially for rusti) could probably do with having a different set of optimizations anyway.

[alexcrichton]

You're probably right about that. I definitely think that it shouldn't be always running certain optimizations by default. Once the dust starts to settle I think that the thing to do would be to hardcode some optimizations into rusti and then perhaps allow a :passes command or something like that.

Edit: or maybe even :optimize

[jedestep]

On today's build I don't seem to be able to reproduce this.

[alexcrichton]

@jedestep, what's your platform/architecture? I just built master on OSX/64-bit and it still has the same problem.

[jedestep]

@alexcrichton I'm on the same platform. The program you pasted will still cause a problem when run with --passes print-module, but the more basic problem seems to have been fixed. Calling signum() in rusti, for example, no longer always prints 1.

[alexcrichton]

That's weird because I routinely get

$ rusti                                             
WARNING: The Rust REPL is experimental and may be
unstable. If you encounter problems, please use the
compiler instead. Type :help for help.
rusti> let a = -50 as f64;
rusti> a.signum() 
1
rusti> 

[alexcrichton]

#7115 has landed, this should be fixed now.

[emberian]

Confirmed fixed