[llvm-bugs] [Bug 46982] New: WebAssembly: float-to-int intrinsics aren't const-propagated

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=46982

            Bug ID: 46982
           Summary: WebAssembly: float-to-int intrinsics aren't
                    const-propagated
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Backend: WebAssembly
          Assignee: unassignedbugs at nondot.org
          Reporter: alex at crichton.co
                CC: llvm-bugs at lists.llvm.org

In the Rust compiler we've been updating the codegen for WebAssembly targets on
float-to-int casts recently. https://github.com/rust-lang/rust/issues/73591 has
a high-level description of the problem, but the basic idea is that
rust-as-the-language defines our `as` operator as safe and saturating. This
causes quite a lot of codegen if we have our own branching and then LLVM has
its own set of branching for the `fptosi` and `fptoui` instructions. Put
another way, LLVM already emits quite a lot of instructions for `fptosi` and
`fptoui`, and we want to avoid that in codegen.

We recently switched to using the `llvm.wasm.trunc.signed.i32.f32` family of
intrinsics for implementing safe float-to-int casts. (this is when the
`+nontrapping-fptoint` argument is not provided, the default). In doing so,
though, we realized that LLVM won't optimize programs quite as much any more,
since the intrinsic is more opaque than the `fptosi` instruction itself. For
example this program:




define i32 @foo() {
start:
  %0 = tail call i32 @llvm.wasm.trunc.signed.i32.f32(float 5.000000e+00)
  ret i32 %0
}

declare i32 @llvm.wasm.trunc.signed.i32.f32(float)




won't get optimized any further, and the final wasm code has `i32.trunc_f32_s`,
generating this assembly:





foo:                                    # @foo
        f32.const       0x1.4p2
        i32.trunc_f32_s
        end_function




Would it be possible to teach the optimizer how to constant evaluate the wasm
float-to-int intrinsics? I'm not entirely sure how else `fptosi` interacts with
the optimizer but this is at least one case we're running into.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20200804/6d714665/attachment-0001.html>