Proposal motivation

[yuri91]

In the last CG meeting some doubts about the usefulness of this proposal have been expressed.

I wrote down the motivations of the proposal here to try to make clearer what the proposal is trying to achieve and why it is not possible to achieve it by other means.

In particular I want to reject the idea that it is possible to implement branch hinting purely in the tools, and that cooperation from the engines is required.

Feedback on the arguments and examples provided is very appreciated.

@aardappel could you give me your thoughts on this?

[aardappel]

One thing that came out of the CG meeting is the need to show the impact of this feature on bigger, more real life benchmarks, rather than a single contrived example. Sadly, we do not have a standard set of benchmarks for Wasm yet (I believe @titzer at some point had plans for this), but would be nice to see the effect of this proposal on any larger Wasm program, or failing that, spec benchmarks or something. I suspect any (interpreted) programming language implementation is also likely to show the advantage of this proposal.

Other architectures are able to solve this problem entirely in the tools. The biggest reason we can't is not necessarily that we're a step disconnected from being a real CPU, but because we don't have arbitrary control flow, as you show in your document.

So while this proposal addresses something Wasm can't express, it essentially expresses one special case: take this conditional block in a loop, and move it out of the loop using the branches we can't express at the Wasm level. It is taking one of many possible branch structures we might want (which for example @sunfishcode 's funclets https://github.com/WebAssembly/funclets/blob/master/proposals/funclets/Overview.md would all solve) and gives it special status.

That is not to say that we don't want this proposal. If funclets is never going to happen, this is better than nothing, it is simple, and unlike funclets is entirely ignorable. But I personally would like to see a bit better numbers and discussion before we commit to something partial like this.

[yuri91]

Arbitrary control flow is only part of the issue: branch hinting can also help with register allocation, and that will always be hidden by Wasm.

And for the code layout problem, I am not sure that funclets can reliably solve the issue: you can express the arbitrary control flow and move the call outside of the loop, but there is nothing telling the engine that you want that code to be distant from the rest in the resulting assembly. The engine could reorder the compilation of funclets based on other heuristics or constraints.

Of course the only way to know for sure is to wait for that proposal to go forward and implementations to appear, but I don't think that this should block the advance of this proposal, at least in the early stages.

It could be useful to have both proposals at some experimental stage to compare the efficiency of the resulting machine code in different implementations. If funclets prove to make branch hinting redundant, then this proposal can be dropped.

Regarding the bigger benchmarks, I agree that they would be nice to have. But it is also difficult to produce them without any tool or engine support.
I know for sure that it can have a big effect on large codebases because I did preliminary tests on one (the CheerpX virtual machine), but before putting the work needed to actually add support to CheerpX and make a benchmark using it available, I would like the spec and binary format to settle.

For phase 2 we need a spec text with enough consensus, and except for some minor issues (#2 and #6 , which I will try to incorporate soon) I don't think that there are major objections to it.

After that, once the feature lands in V8 behind an experimental flag (on which I am working on), I plan to find a suitable medium sized benchmark, and eventually a demo featuring CheerpX.

EDIT: I dind't point it out in the motivation , but you can notice the effect on register allocation in that example as well: rax and rbx are spilled on the stack unconditionally without hints, but only after the jump with hints.

[aardappel]

but there is nothing telling the engine that you want that code to be distant from the rest in the resulting assembly. The engine could reorder the compilation of funclets based on other heuristics or constraints.

It can, but has no reason to, and likely generally won't. Wasm engines typically assume that the code they receive has gone through a high level of LLVM (and Binaryen) optimization, so unless they know for sure there is something they know they can do better than LLVM, they will probably stick to the code as-is.

but I don't think that this should block the advance of this proposal

I see them as having overlapping functionality, with one of the two being more general and having other benefits. That said, I am just bringing up issues as I see them.

[yuri91]

Closing this, since the motivations have been discussed at length in CG-03-02