[PATCH] D154639: [WebAssembly] Add frexp{f,l} libcall signatures

Thu Jul 6 13:23:15 PDT 2023

dschuff added inline comments.

================
Comment at: llvm/test/CodeGen/WebAssembly/libcalls.ll:261
+; CHECK-NEXT:    call $push8=, ldexp, $pop19, $pop7
+; CHECK-NEXT:    call llvm.frexp.f64.i32, $pop20, $pop8
+; CHECK-NEXT:    local.get $push22=, 3
----------------
sbc100 wrote:
> sbc100 wrote:
> > dschuff wrote:
> > > sbc100 wrote:
> > > > How is `llvm.frexp.f64.i32` implemented?  Is it supposed to be the name of a function compiler-rt?   
> > > it's a libm function, like the other functions in this test. IIRC some of the libcalls might be compiler-rt, I'm not sure LLVM differentiates. Also the list of intrinsics doesn't really differentiate between ones that lower directly to libcalls and ones that don't, because it depends on the architecture (e.g. if there are instructions that map directly or not). In this case wasm doesn't really have a direct equivalent for frexp.
> > But how can libm implement a function called `llvm.frexp.f64.i32`.. wouldn't you need a name without periods in it if you want to be able to implement it in C?
> The other callees here have names like `__powidf2`
Sorry, the target-independent lowering code translates the intrinsic (named `@llvm.frexp.f64.i32` or `@llvm.frexp.f32.i32`) into a call to the library function (named `frexp` or `frexpf`). 

Oh, but I see the problem here, the call in the generated code in this test is wrong! It looks like there was some kind of accident with update_llc_check_tests.py, I'm not sure what happened there. I fixed that

(Also yes, I missed `__powidf2`. I assume that one is a compiler-rt function)

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D154639/new/

https://reviews.llvm.org/D154639