[PATCH] D95125: [WebAssembly] Enable loop unrolling

Sjoerd Meijer via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Jan 26 08:38:42 PST 2021


SjoerdMeijer added a comment.

In D95125#2522699 <https://reviews.llvm.org/D95125#2522699>, @kripken wrote:

> But I think the question is where loop unrolling is done: on the wasm producer (LLVM) or the wasm consumer (the VM that runs it).

Ok, thanks, fair enough.

> As mentioned earlier VMs are working on this, and the benefit of them doing it is that code size matters quite a bit on wasm, and doing it there would be better.

Like I said, I am not from this field, but I don't see according to which criteria this is better:

- In terms of implementation, I guess letting the LLVM based producer do the loop-unrolling is better as loop-unrolling is a non-trivial optimisation (to do this properly) to (re)implement, this is leveraging the existing LLVM infrastructure, and enabling this is a few lines of code which much beat reimplementing loop-unrolling in a consumer.
- Generated code-quality: assuming 2 loop-unrollers do their job equally well, there shouldn't be any performance difference. Unless the runtime uses profile information that is fed back or has more target information.
- Code-size: this should be the same in the end? I.e., for people interested in maximum performance, doing unrolling in the producer shouldn't increase code-size compared to when this done at the consumer side. For folks that want better code-size, there are different knobs to steer this.
- Compile times: doing loop-unrolling at the consumer side will impact start-up or install times?
- Availability of loop-unrolling. Doing the transformation in the wasm consumer (once) avoids needing it in the different producers and would thus be better. That is, if there is 1 consumer. If there are multiple consumer implementations, then there is no difference?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D95125/new/

https://reviews.llvm.org/D95125



More information about the llvm-commits mailing list