- Where: zoom.us
- When: November 9th, 5pm-6pm UTC (November 9th, 9am-10am Pacific Time)
- Location: link on calendar invite
None required if you've attended before. Send an email to the acting WebAssembly CG chair to sign up if it's your first time. The meeting is open to CG members only.
The meeting will be on a zoom.us video conference. Installation is required, see the calendar invite.
- Opening, welcome and roll call
- Opening of the meeting
- Introduction of attendees
- Find volunteers for note taking (acting chair to volunteer)
- Adoption of the agenda
- Proposals and discussions
- Update on Branch Hinting (Yuri Iozzelli) [20 min]
- Poll for Phase 3
- Update on Relaxed SIMD (fpenv discussions) and poll for phase 2 (Zhi An Ng) [15 min]
- Update on Custom Annotations (Andreas Rossberg) [15 min]
- Poll to move to stage 4
- Update on Branch Hinting (Yuri Iozzelli) [20 min]
- Closure
None
None
Deepti Gandluri
Steven Prime
Andreas Rossberg
Francis McCabe
Chris Fallin
Bailey Hayes
Lars Hansen
Zhi An Ng
Alex Chichton
Keith
Yuri Iozzelli
Sam Clegg
Rick Battagline
Paolo Severini
Ryan Hunt
Sergey Rubanov
Zalim Bashorov
Alon Zakai
Jaco b G
Andrew Brown
Yuri Iozelli
Dan Gohman
Conrad Watt
Thomas Lively
David Piepgrass
Sean Jensen-Grey
Ben Titzer
Dmitriy Bezhetskov
Mingqui Sun
Radu Matei
Slava Kuzmich
Jakob Kummerow
Asumu Takikawa
Intel Seven
Paul Shoenfelder
Petr Penzin
Peter Huene
Nick “fitzgen” Fitzgerald
Heejin Ahn
Ross Tate
Arun Purushan
Emanuel Ziegler
Acting chair to volunteer
Update on Custom Annotations (Andreas Rossberg) [15 min]
Presentation on Custom Section Annotations by Andreas Rossberg
AR: Motivation is that binary format has support for custom section, but want to be able to represent something similar in the text format
BT: Free form, but should braces be balanced?
AR: Yes, almost free form. Needs to be parseable by tools that do not understand that specific section. The syntax is a sequence of tokens, which can include parentheses inside string literals
Keith (in chat): Do we specify an encoding for the strings?
Francis(in chat): what about connecting the text annotations to custom sections
DP (in chat): It sounds to me like the syntax with the byte-sequence should be part of the Wasm standard rather than merely an "example" as the slide says
BT (in chat): The text format allows strings with escaped byte sequences At least in .wast So binary tests (.bin.wast) have modules that are specified in binary as strings with escapes
JG (in chat): I think there's a symmetry between the custom annotations and custom sections, so any ways you can go wrong with one you can go wrong with the other which is to say, we already have the problems of annotations in the binary format, so it's already something we're living with
YI: Interested in the discussion about testing, similar to branch hinting. Same problem, no way to add tests for Branch hinting in the current ecosystem. Should I be addressing this? Interesting problem, glad we’re talking about it
AR: We should decouple from specific problems, who would be willing for the volunteer?
FM: What happens if an engine has implemented an annotation scheme, someone is using the annotation scheme but in an incorrect way.
AR: Same as custom sections, the spec is clear that engine should not reject a malformed custom section. If there’s a malformed custom section it should ignore it, but not reject the module. Similar pattern expected for malformed annotations. You shouldn’t refuse to consume the module.
PP: Can you easily reject a malformed section, in a binary it doesn’t apply, in this case you would read it and may need to compile the module differently. Other languages could support these type of annotations. This would be ok to do with the text format
AR: Yes, and no. Text format is the textual representation so it should be equivalent. Annotation shouldn’t modify the semantics of the semantics of execution, so should be ok to ignore
FM: that's unrealistic
AR: depends on what the tool wants to do, less clear cut with text format
FM: suppose i'm compiling java, suppose i'm using annotations to fill in the gaps that Wasm can't support, like names. A tool expecting java like Wasm is expecting to see those annotations, expect them to follow rules
AR: if you are a tool dependent on certain annotations, then you can't do much if you don't understand them. If there are other custom annotations you don't understand, you should sitll ignore them.
AR: Ultimately tools are free to whatever they want to do with it, it’s
DG: Does anyone block phase 4?
LH: Mild objection as it looks like we need more discussion, with respect to the tests as well as what happens when we encounter a malformed annotation. We pushed YI pretty hard on tests, and the same standard should be applied here as well. Could use more discussion.
Update on Branch Hinting (Yuri Iozzelli) [20 min]
YI presenting Slides
KM (in chat): Should be trivial for JSC excluding the interpreter (in response to how tricky is this to implement in engines other than V8?)
BT: (in chat) Won’t really help in an interpreter IMO, So can just ignore the custom section In contrast to the constant time proposal, which also needs to be supported in the interpreter, where we decided to have new instructions
LH (in chat): I don’t think Firefox has a good notion of hot/cold code at this time, would need to be added to support hints
RW: Have you done any workload testing, where you have some data from workloads.
YI: Test using CheerpX (extra benchmarks slide), compared benchmarks with/without branch hinting. Testing is not easy because in general branch hinting is not needed. Native programs don’t also always have them. But for some applications it doesn give 10-20% speedups
RW: Is this from CPU speculation?
YI: Definitely not, if V8 knows something unlikely to be used it doesn’t need to put it on the stack
RW: Is the workload publicly available?
YI: Had it uploaded, can add it again. <LINK: https://repl.leaningtech.com/benches/index.html>
PP: Tool is proprietary
YI: Tool is not open source, but the compiled version can be analyzed as needed. Can test with/without flage
PP: Is it correct that it’s an x86 binary transpiled to Wasm
YI: There’s a jit compiler inside that generates the Wasm
PP: IT’s not the most common usecase
YI: Agree, not commonly, it’s not useful in some cases
PP: Tools eliminate this behavior, will this mean that this was already addressed?
YI: < PHASE 3 slide> The idea is that other proposals use custom sections in the same way with similar instrumentation, tools may not be able to keep up with different formats. If all the proposals stick to the same format, the cost of having a common framework will be shared
RW: We’ve changed the implementation to match this format
PP: Code annotations can indicate which custom sections are malformed and throw them away, how does it do that
YI: if tools start adding support for code annotations, then i expect the ecosystem to understand these annotations in general, e.g. wabt can understand any annotation after i added support. For wabt it is easier than binaryen, since binaryen is changing the module. You can add support for parsing them, and add support to its IR.
YI: POC of adding a code annotation in llvm (very partial but to have an idea on how it could look like): https://github.com/yuri91/llvm-project/tree/annotations
Poll Branch hinting to phase 3
| SF | F | N | A | SA |
|---|---|---|---|---|
| 7 | 18 | 6 | 0 | 0 |
Congrats to branch-hinting proposal for Phase 3
CW: How robust do you expect this to be if there’s a new architecture comes up?
ZA: That’s not realistic at the time, because ti might be hard for Wasm itself to support
AR: I thought the text was saying each result is specified as lists of sets, should it say list and not a set as it is unordered? And each element in the list can be
ZA: That’s correct
CW: Do you think in practise people will rely on having results picked from the same column?
ZA: Yes, example is the fuse operations
BT: IS it correlated across different instructions, i.e. are there families of results? Across different instructions?
PP: That’s more per architecture, not family of instructions
BT: Does that need to be in the spec that you would get this column or that column across multiple architectures
ZA: Don’t think so - that’s not necessary, for example we only want fused or non-fused. Right now the way we specify it doesn’t cross instruction bopundaries DaG: Some instructions have that correspondence right, we should label it
ZA: We would have to label it in some way yes
AR: We could get away with funneling similar operations across in some way
ZA: Besides FMA AND FMS there won’t be other combinations so we won’t want
DaG: Min/Max also come to mind
LH (in chat): Preventing the migration is sort of the point though, that was the point of fpenv and this is the child of that
ZA: It’ll be weird that architectures do that, we can have a meta instruction that does that. The broader idea is that the results don’t jump between the two columns
PP: Pseudocode in the overview has what is supposed to happen, and what is implementation defined, there’s much more detail there.
ZA: We don’t really want implementation defined results, that’s what we’re trying to fix here. We want it to be defined
PP: The text will be only different in some cases, -0, +0, NaN etc. Very narrow cases
RT: You can say implementation defined up to a certain point
ZA: That’s what this column is doing
PP: This is still fine in that direction
RT: Where things get weird is, out of these two columns there are two independent choices, but now you’re saying they’re correlated choices. One is consistency across discussions, constrained implementation defined ness
NF (in chat): idle thought: this would preclude live migrating a wasm instance from x64 to aarch64, since the wasm could observe the difference in results of these nondeterministic instructions or even using something like Wizer (https://github.com/bytecodealliance/wizer/) to initialize a Wasm instance on x64 and then run it later on aarch64
POLL: Relaxed-simd to Phase 2
| SF | F | N | A | SA |
|---|---|---|---|---|
| 10 | 6 | 7 | 1 | 0 |
Congratulations to relaxed-simd for advancing to Phase 2!
ZA: Reasons for against votes?
DaG: Just in terms of priorities, adding non-determinism
