[WebAssembly] Fix signatures of frexpf family of libcalls

[sbc100]

Fixes: emscripten-core/emscripten#23997

[sbc100]

Not sue where the tests are for this stuff..

[llvmbot]

@llvm/pr-subscribers-backend-webassembly

Author: Sam Clegg (sbc100)

Changes

Fixes: emscripten-core/emscripten#23997

---

Full diff: https://github.com/llvm/llvm-project/pull/133289.diff

1 Files Affected:

• (modified) llvm/lib/Target/WebAssembly/WebAssemblyRuntimeLibcallSignatures.cpp (+3-3)

diff --git a/llvm/lib/Target/WebAssembly/WebAssemblyRuntimeLibcallSignatures.cpp b/llvm/lib/Target/WebAssembly/WebAssemblyRuntimeLibcallSignatures.cpp
index 94d80f19e48af..ce795d3dedc6a 100644
--- a/llvm/lib/Target/WebAssembly/WebAssemblyRuntimeLibcallSignatures.cpp
+++ b/llvm/lib/Target/WebAssembly/WebAssemblyRuntimeLibcallSignatures.cpp
@@ -278,9 +278,9 @@ struct RuntimeLibcallSignatureTable {
     Table[RTLIB::LDEXP_F32] = f32_func_f32_i32;
     Table[RTLIB::LDEXP_F64] = f64_func_f64_i32;
     Table[RTLIB::LDEXP_F128] = i64_i64_func_i64_i64_i32;
-    Table[RTLIB::FREXP_F32] = f32_func_f32_i32;
-    Table[RTLIB::FREXP_F64] = f64_func_f64_i32;
-    Table[RTLIB::FREXP_F128] = i64_i64_func_i64_i64_i32;
+    Table[RTLIB::FREXP_F32] = f32_func_f32_iPTR;
+    Table[RTLIB::FREXP_F64] = f64_func_f64_iPTR;
+    Table[RTLIB::FREXP_F128] = i64_i64_func_i64_i64_iPTR;
     Table[RTLIB::MODF_F32] = f32_func_f32_iPTR;
     Table[RTLIB::MODF_F64] = f64_func_f64_iPTR;
     Table[RTLIB::MODF_F128] = i64_i64_func_i64_i64_iPTR;

[dschuff]

LGTM too but if you want to improve the tests, they are in llvm/test/CodeGen/WebAssembly/libcalls.ll. It looks like it covers frexp but It actually doesn't look like we have coverage for memory64 at all.

[sbc100]

LGTM too but if you want to improve the tests, they are in llvm/test/CodeGen/WebAssembly/libcalls.ll. It looks like it covers frexp but It actually doesn't look like we have coverage for memory64 at all.

I looked into modifying test/CodeGen/WebAssembly/libcalls.ll and using -DPTR=i32/i64 to make it pass in both modes. But then I realized that its output is auto-generated/auto-updated. So that other option is it clone that test and make a separate file, but that makes it little harder to see how the wasm32 and wasm64 version vary.

What is the best approach here? Clone it and use auto-updated? Or stop using auto-update and manually encode the differences?

I'm think a clone will be easier in the long run, even though it involves some duplication.

@tlively @dschuff WDYT?

[dschuff]

Cloning seems OK.
I suppose the "real" best longterm solution would be to somehow infer the libcall signatures, although there wasn't an easy way to do it when I wrote this in the first place, since the type lowering code is buried in codegen and I'm not sure how hard it would be to extract. There have been 9 changes to this file in the past 2 years, which seems like somewhere between "no maintenance burden/risk" and "definitely worth fixing".

[llvm-ci]

LLVM Buildbot has detected a new failure on builder llvm-clang-x86_64-darwin running on doug-worker-3 while building llvm at step 6 "test-build-unified-tree-check-all".

Full details are available at: https://lab.llvm.org/buildbot/#/builders/23/builds/8940

Here is the relevant piece of the build log for the reference

Step 6 (test-build-unified-tree-check-all) failure: test (failure)
******************** TEST 'Clang-Unit :: DirectoryWatcher/./DirectoryWatcherTests/2/8' FAILED ********************
Script(shard):
--
GTEST_OUTPUT=json:/Volumes/RAMDisk/buildbot-root/x86_64-darwin/build/tools/clang/unittests/DirectoryWatcher/./DirectoryWatcherTests-Clang-Unit-72520-2-8.json GTEST_SHUFFLE=0 GTEST_TOTAL_SHARDS=8 GTEST_SHARD_INDEX=2 /Volumes/RAMDisk/buildbot-root/x86_64-darwin/build/tools/clang/unittests/DirectoryWatcher/./DirectoryWatcherTests
--

Script:
--
/Volumes/RAMDisk/buildbot-root/x86_64-darwin/build/tools/clang/unittests/DirectoryWatcher/./DirectoryWatcherTests --gtest_filter=DirectoryWatcherTest.AddFiles
--
/Users/buildbot/buildbot-root/x86_64-darwin/llvm-project/clang/unittests/DirectoryWatcher/DirectoryWatcherTest.cpp:259: Failure
Value of: WaitForExpectedStateResult.wait_for(EventualResultTimeout) == std::future_status::ready
  Actual: false
Expected: true
The expected result state wasn't reached before the time-out.

/Users/buildbot/buildbot-root/x86_64-darwin/llvm-project/clang/unittests/DirectoryWatcher/DirectoryWatcherTest.cpp:262: Failure
Value of: TestConsumer.result().has_value()
  Actual: false
Expected: true

libc++abi: terminating due to uncaught exception of type std::__1::system_error: condition_variable wait failed: Invalid argument

/Users/buildbot/buildbot-root/x86_64-darwin/llvm-project/clang/unittests/DirectoryWatcher/DirectoryWatcherTest.cpp:259
Value of: WaitForExpectedStateResult.wait_for(EventualResultTimeout) == std::future_status::ready
  Actual: false
Expected: true
The expected result state wasn't reached before the time-out.

/Users/buildbot/buildbot-root/x86_64-darwin/llvm-project/clang/unittests/DirectoryWatcher/DirectoryWatcherTest.cpp:262
Value of: TestConsumer.result().has_value()
  Actual: false
Expected: true



********************