[PATCH] D95125: [WebAssembly] Enable loop unrolling

[Alon Zakai via Phabricator via llvm-commits]

kripken added a comment.

In D95125#2522915 <https://reviews.llvm.org/D95125#2522915>, @SjoerdMeijer wrote:

> In D95125#2522699 <https://reviews.llvm.org/D95125#2522699>, @kripken wrote:
>
>> 
>
>
>
>> 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.

Fair point. Note however that LLVM is not the only producer, and some do not do loop unrolling. But as you said lower down, some VMs might not do it, etc. so definitely there are tradeoffs here.

> - 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.

Are you thinking of machine code size? That matters too, but the bigger concern is wasm binary size, which is what is downloaded. Doing unrolling after the download is better for that.

> - Compile times: doing loop-unrolling at the consumer side will impact start-up or install times?

Yes, that is a definitely a downside, and it is why we usually prefer to optimize in the producer. Optimizations that increase code size, however, are where the tradeoffs become more interesting, like here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95125