weixin_39636609
2020-12-02 03:19 阅读 23

Use wasm-opt?

Another option in this space is Binaryen's wasm-opt tool, which has optimizations to remove unneeded code, doing something like

`
wasm-opt input.wasm -Os -o output.wasm

` It also merges duplicate functions, reorders them to optimize the efficiency of wasm LEB encoding, etc., and other wasm-specific minification tricks. Might be worth making it easy to run it on rust wasm files.

该提问来源于开源项目:alexcrichton/wasm-gc

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享

8条回答 默认 最新

  • czvi5518 czvi5518 2020-12-02 03:19

    Oh definitely sounds plausible! Right now the main purpose of this tool is to just recover some of the deficiencies about not having a linker, primarily related to compiler-rt intrinsic definitions. We have to fake LLVM into exporting all the compiler-rt intrinsics to ensure they make their way to the end if they're used (afaik we can't detect which ones are needed). The wasm-gc tool is just then useful for eliminating the unused functions after the fact by just crawling the wasm and walking references and such.

    That being said this tool won't be necessary with lld just around the corner, and I also definitely don't plan to add many optimizations here!

    Would wasm-opt remove export annotations? I'd imagine that by default it probably preserves them, but if it does then sounds like we should just use that instead!

    点赞 评论 复制链接分享
  • weixin_39636609 weixin_39636609 2020-12-02 03:19

    It doesn't do any destructive changes by default, just optimizations that preserve the same behavior. I didn't realize this tool did more than just gc, it also removes exports in order to let gc do more things?

    点赞 评论 复制链接分享
  • czvi5518 czvi5518 2020-12-02 03:19

    Yeah in general this performs a generic "gc everything" pass but it has a hardcoded blacklist of exports where, if found, they'll forcibly not be exported from the result (and then they're naturally gc'd unless they're otherwise referenced)

    点赞 评论 复制链接分享
  • czvi5518 czvi5518 2020-12-02 03:19

    The blacklist being this one

    点赞 评论 复制链接分享
  • weixin_39636609 weixin_39636609 2020-12-02 03:19

    I see, thanks. Sounds like this is more rust/wasm specific than I realized.

    Binaryen optimizer can still help with other things though, if you want. I tested on one of the binaries in the HN thread and it shrank it by 6% - which is typical of what it can do on LLVM wasm backend output.

    点赞 评论 复制链接分享
  • czvi5518 czvi5518 2020-12-02 03:19

    Nice! I'll definitely be recommending that to everyone who wants smaller binaries in that case.

    Do you think those sorts of optimizations will eventually make their way into LLVM? Or will the wasm-opt style tool likely be a part of the wasm workflow for awhile?

    点赞 评论 复制链接分享
  • weixin_39636609 weixin_39636609 2020-12-02 03:19

    I think wasm => wasm optimizers/minifiers like Binaryen will be pretty standard, yeah.

    LLVM might add more optimizations over time, but these types of optimizations are best done on a wasm-specific IR, and adding a completely new IR in one specific LLVM backend would be tricky politically and technically. Second, there is ecosystem pressure to write such optimizations in a more central place anyhow, where they can be run on wasm directly no matter what compiler emitted it, LLVM or otherwise. So it's easier and better to write those in a place like Binaryen, and for users, it's just one simple commandline operation.

    点赞 评论 复制链接分享
  • czvi5518 czvi5518 2020-12-02 03:19

    Ok cool! Sounds like wasm-opt isn't applicable for wasm-gc's very narrow and specific use case (eliminating compiler rt goo) and otherwise when we document wasm for rust we should for sure mention wasm-opt and binaryen!

    点赞 评论 复制链接分享

相关推荐