Replacing `memset` and `memcpy` calls with `memory.fill` and `memory.copy`?
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
- Issue type
- Feature
- Clarity
- Needs clarification
- Activity status
- Stale
- Tech stack
- wasm
- Domain
- compilers
Research direction
Start by reviewing the wasm-opt pass architecture and how the bulk-memory feature gates memory.fill and memory.copy. Determine whether the pass should recognize named memset/memcpy calls or control-flow loops, then confirm the accepted scope and define tests showing the intended replacements.
Written by the indexing model from the issue text.
Description
If I were to try working on a wasm-opt pass doing what's written in the title, would it be accepted? Gated behind the bulk-memory extension/feature of course.
The rationale I have for this is that when compiling Rust, even with the bulk-memory target feature (codegen option) enabled, a lot of naive (slow) memcpy and memset calls are left in the result, because they are called from std/core library functions, such as __rust_alloc_zeroed and __rust_realloc. These can be avoided by passing the build-std option to Cargo, but that is still an unstable, nightly-only feature.
Of course, this sets some assumptions about what a function that happens to be named "memset" or "memcpy" is supposed to be doing, but in a lot of compiler toolchains, these are pretty much already handled as intrinsics anyway.
One alternative would be to detect some forms of memory copying or filling loops in the control flow graph instead, and only replace those with intrinsics.
What do you think?
- Dominant language
- WebAssembly
- Stars
- 8.6k
- Forks
- 885
- Avg merge
- 2d 1h
- Merged PRs (30d)
- 70
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from WebAssembly/binaryen
-
Difficulty 2/5 Half a day Newbie friendliness 76/100
WebAssembly/binaryen#9018 · 3 comments ·
-
Difficulty 4/5 3-5 days Newbie friendliness 52/100
WebAssembly/binaryen#9123 ·
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
WebAssembly/binaryen#9122 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
WebAssembly/binaryen#9086 · 2 comments ·
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
WebAssembly/binaryen#9038 · 5 comments ·
All issues in WebAssembly/binaryen
Similar issues
-
compiler/runtime
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
objectionary/eo#8869 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
EricSpencer00/Resilient#4824 · 1 comment ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
objectionary/jeo-maven-plugin#1758 ·
-
generics
Difficulty 2/5 1-3 hours Newbie friendliness 82/100