Unregisterised code size is two orders of magnitude too large

[ElvishJerricco]

Just opening an issue for something we've known about for a couple weeks now. Binary sizes are on the order of 100M, which is clearly absurd. @dfordivam thinks this is due to a lack of DCE. This problem is present both with the wasm backend and the native unregisterised backend, so maybe this should be an issue on GHC trac.

As for solutions, it seems reasonable that we could implement some kind of DCE despite the trampolining the C code does. But another idea we had was to switch to the LLVM backend before wasm has tail calls. We could write an implementation for the GHC calling convention (ghccc) that lowers calls into a trampoline ABI. If we enable LTO in LLVM, we might get DCE in the linker before lowering out of bitcode, just based on the ghccc calls.

[dfordivam]

I checked the lld code, the --gc-sections code (markLive) is done after the LTO compilation.
So the LTO idea might not work if we add trampolining during the compilation phase.
I will study the markLive code further, if we can make it smart enough / fine granularity to be able to do DCE.
Since the garbage collection happens at the level of sections, maybe breaking down the object code into smaller sections might do the trick...

[ElvishJerricco]

It's possible that the LLVM level LTO optimizations perform DCE, before passing on to the linker's --gc-sections.

[dfordivam]

For the linux unregistered build I managed to make the --gc-sections to work by fixing the -split-sections option in ghc for unregistered build. The size of exe reduced from 17mb to 3.5mb for hello-world program. It is still ~3.5x the native exe size, but we got more than 4x reduction.

I got the hint about using -ffunction-sections -fdata-sections from the LTO source code. The code seems to just compile the bitcode in a normal way to object code and adding stuff to symbol table, but by default it generated separate sections. Here is the snippet of the code from lld.

  // Always emit a section per function/datum with LTO.
  C.Options.FunctionSections = true;
  C.Options.DataSections = true;

I tried the same thing for wasm-cross-ghc, but the output was exactly same as before, 27mb.
The reason is that the --gc-sections is already working for wasm target. I used --print-gc-sections, (using the latest lld HEAD, version 8), and found that about 300k sections are removed from the jsaddle app. The remaining data+code are 200k, so more than half are already being removed. I double checked this by disabling --gc-sections; the exe is now 54mb, almost the same size as unregistered native linux build.