Massive memory growth for -O3, -O4, -Os and -Oz, in ssa-nomerge

Open
#7,644 7 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
25/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Stale
Tech stack
go, wasm
Domain
compilers, performance

Research direction

Reproduce the memory growth with the attached hegelmote-wasm.zip using the shown wasm-opt command and compare -O1/-O2 with -O3, -O4, -Os, and -Oz. Read the related Binaryen issue 3646 and trace the optimizer entry points reached by these levels; done means the affected optimization levels no longer exhaust system memory on the reference file.

Written by the indexing model from the issue text.

Description

Hi. I am planning on applying wasm-opt to my Go project as part of https://github.com/Jacalz/hegelmote/pull/30. The Go WASM files are generally quite big and our toolkit is not super optimised for WASM yet so I wanted to optimise it. As I was interested in seeing which level made the most sense, I aimed to run all of the levels to see how long they take and how they affect the binary size. What I unfortunately found out was that O1 and O2 were the only ones that were usable as -O3, -O4, -Os and -Oz all seem to use memory exponentially until all 32 GB are full. I have attached the file below if you wish to try and reproduce it.

Results:
  • Baseline: 37.3 MB
  • O1: 35.7 MB, 29.85 s
  • O2: 35.7 MB, 32.78 secs
  • O3: DNF
  • O4: DNF
  • Os: DNF
  • Oz: DNF

Running:

wasm-opt Hegelmote.wasm --enable-bulk-memory-opt -O3 -o O3.wasm

Potentially related to https://github.com/WebAssembly/binaryen/issues/3646.

Reference file: hegelmote-wasm.zip

Dominant language
WebAssembly
Stars
8.6k
Forks
885
Avg merge
1d 20h
Merged PRs (30d)
64

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from WebAssembly/binaryen

All issues in WebAssembly/binaryen

Similar issues

More Compilers issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.