[Git][ghc/ghc][wip/marge_bot_batch_merge_job] 3 commits: wasm: bump dyld v8 heap size limit

[Marge Bot (@marge-bot)]

Marge Bot pushed to branch wip/marge_bot_batch_merge_job at Glasgow Haskell Compiler / GHC


Commits:
91c15797 by Cheng Shao at 2025-02-21T23:20:49-05:00
wasm: bump dyld v8 heap size limit

This patch sets `--max-old-space-size=65536` as wasm dyld shebang
arguments to lessen v8 heap pressure in certain workloads that load
the full ghc package. It doesn't really commit 64G memory but it does
help reduce v8 gc overhead.

- - - - -
4beecd22 by Cheng Shao at 2025-02-21T23:20:49-05:00
wasm: fix dyld for shared libraries created by llvm 20.x

This patch fixes wasm dyld script for shared libraries created by llvm
20.x. The __wasm_apply_data_relocs function is now optional and may be
omitted for shared libraries without any runtime relocatable data
segments, so only call __wasm_apply_data_relocs when it's present.

- - - - -
b0629450 by Cheng Shao at 2025-02-21T23:20:49-05:00
driver: fix wasm backend sysroot lookup logic when -flto is passed

For the wasm target, the driver calls `wasm32-wasi-clang
--print-search-dirs` and finds the sysroot directory that contains
libc.so etc, then passes the directory path to dyld. However, when GHC
is configured with -flto as a part of C/C++ compiler flags, the clang
driver would insert a llvm-lto specific directory in the
--print-search-dirs output and the driver didn't take that into
account. This patch fixes it and always selects the non-lto sysroot
directory to be passed to dyld. This is one small step towards
supporting building all cbits with lto for wasm.

- - - - -


2 changed files:

- compiler/GHC.hs
- utils/jsffi/dyld.mjs


Changes:

=====================================
compiler/GHC.hs
=====================================
@@ -717,11 +717,7 @@ setTopSessionDynFlags dflags = do
 #if defined(wasm32_HOST_ARCH)
         let libdir = sorry "cannot spawn child process on wasm"
 #else
-        libdir <- liftIO $ do
-          libdirs <- Loader.getGccSearchDirectory logger dflags "libraries"
-          case libdirs of
-            [_, libdir] -> pure libdir
-            _ -> panic "corrupted wasi-sdk installation"
+        libdir <- liftIO $ last <$> Loader.getGccSearchDirectory logger dflags "libraries"
 #endif
         let profiled = ways dflags `hasWay` WayProf
             way_tag = if profiled then "_p" else ""


=====================================
utils/jsffi/dyld.mjs
=====================================
@@ -1,4 +1,4 @@
-#!/usr/bin/env -S node --disable-warning=ExperimentalWarning --experimental-wasm-type-reflection --max-old-space-size=8192 --no-turbo-fast-api-calls --wasm-lazy-validation
+#!/usr/bin/env -S node --disable-warning=ExperimentalWarning --experimental-wasm-type-reflection --max-old-space-size=65536 --no-turbo-fast-api-calls --wasm-lazy-validation
 
 // Note [The Wasm Dynamic Linker]
 // ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -796,12 +796,17 @@ class DyLD {
 
       const init = () => {
         // See
-        // https://github.com/llvm/llvm-project/blob/llvmorg-19.1.1/lld/wasm/Writer.cpp#L1430,
-        // there's also __wasm_init_memory (not relevant yet, we don't
+        // https://gitlab.haskell.org/haskell-wasm/llvm-project/-/blob/release/20.x/lld/wasm/Writer.cpp#L1450,
+        // __wasm_apply_data_relocs is now optional so only call it if
+        // it exists (we know for sure it exists for libc.so though).
+        // There's also __wasm_init_memory (not relevant yet, we don't
         // use passive segments) & __wasm_apply_global_relocs but
         // those are included in the start function and should have
-        // been called upon instantiation.
-        instance.exports.__wasm_apply_data_relocs();
+        // been called upon instantiation, see
+        // Writer::createStartFunction().
+        if (instance.exports.__wasm_apply_data_relocs) {
+          instance.exports.__wasm_apply_data_relocs();
+        }
 
         instance.exports._initialize();
       };



View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/c585d8b92c954f24a804e918d32eaea19e438aff...b06294507456231391b91f17316bb0312f2de752

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/c585d8b92c954f24a804e918d32eaea19e438aff...b06294507456231391b91f17316bb0312f2de752
You're receiving this email because of your account on gitlab.haskell.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-commits/attachments/20250221/eb4a52c9/attachment-0001.html>