- Where: zoom.us
- When: August 15th, 4pm-5pm UTC (August 15th, 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)
- Proposals and discussions
- Update on Branch Hinting [Yuri Iozzelli, 20 min]
- Poll: Advance Extended Name Section to Phase 2 [Ashley Nelson, 10 min]
- Closure
None
None
- Chris Woods
- Yuri Iozzelli
- Derek Schuff
- Thomas Lively
- Justin Michaud
- Francis McCabe
- Nick Fitzgerald
- Paolo Severini
- Ryan Hunt
- Saul Cabrera
- Conrad Watt
- Jeff Charles
- Dan Gohman
- Alon Zakai
- Matthew Yacobucci
- Ben Titzer
- Pat Hickey
- Shoaib
- Bailey Hayes
- Johnnie Birch
- Nick Ruff
- Petr Penzin
- Ashley Nelson
- Saúl Cabrera
YI presenting slides
FM: In the the branch hinging custom sections, is there a spec version associated with the section? (i.e. so you can tell what version of the spec the hint is for)?
YI: no, although this can be easily worked around by the nature of the sections. E.g. if there needs to be a change in the format, we can just change the name of the section. Then we don’t break anything. If browsers stop supporting the old version, then it just gets a little slower because the hints aren’t recognized. I don’t really see that as likely with branch hinting though.
FM: One alternative to having a new kind of custom section would be to version the custom section. Have a new version of the spec, maybe not for branch hinting, with additional functionality.
YI: For future things, definitely possible, there is a general structure of custom instructions attached. There are only two proposals that are using it for now. Branch hinting and Instrument tracing technology. They can both use it. Future things may need it that’s not taken into account. I think v2 at that point. The names are quite freely chosen. So we could have v1 in the name right now.
FM: Thanks
CW: I saw when you mentioned toolchain support, you didn’t mention Binaryen. Do you have any perspective on that, whether Binaryen might support that?
YI: I cannot speak for Binaryen. I think it would similar to preserving DWARF information. Binaryen takes wasm in and produces wasm out with stuff in the middle. The most difficult thing of preserving custom section is changing the custom section, then I need to change the hints. If I flip the branch to the opposite meaning, then I need to flip the meaning of the ints. I think this is similar to preserving the DWARF but easier because it’s optimized information and not for debugging. But every optimization pass would need to think about this. Some information needs to be attached to the instruction and proper care. I cannot speak of a plan for doing anything in Binaryen right now.
TL: that’s correct. We don’t have concrete plans to implement it, although it would be useful. The part where we update instruction offsets would be no problem, we have things that do that already. And I agree that the tricky part would be where we have optimizations that change branches. We’d probably just drop them if we did the minimum. Hard to say how many would make it through. Doing it properly would be more effort but could be done.
RH: Have you done any data collection on the binary size overhead. Say you have a module and you want to annotate. Do you annotate most branches, some, little?
YI: It’s a bit complex of a question. If e.g. we have an average C++ codebasse we wouldn’t expect a lot. If you’re not very sure the branch is very likely or very unlikely you would’nt add a hint, because you risk making it worse. So I’d expect just a small fraction of branches. If you look in a codebase you can search for e.g. __builtin_expect and there aren’t many in most codebases. So I wou’dn’t expect a lot. There’s also my actual usecase, which isn’t this but JIT-generated code for a runtime. In our x86 VM or a Jav JIT, etc. In that case I would imagine more e.g. for checks/bailouts for slow paths. So there will be a lot more and they are almost never taken. So they are generated at runtime, so my guess would be for AOT codebases there would be few, but more for JITs.
RH: Thanks
YI: if you want to try to reproduce this, there is a basic benchmark (link in the “benchmarks” slide).
DS: Sounds close to being ready for stage 4, what are the mechanics? Sounds like we need to push annotations to stage 4 first, this is a one-way dependency, right?
YI: Yes. My idea would be as soon as custom annotations goes to Phase 4, try for Branch Hinting as well.
DS: In principle, they could even be voted together
AN: presenting overview.md
AN: there is quite a bit of support for this already, in V8, Binaryen and emscripten for various name types. We are trending toward phase 4 level of readiness, so I wanted to see what support was like for adding the missing entities, and we should definitely go to phase 2.
FM: does tag name refer to exception tag?
AN: yes
YI: is there an equivalence for the entities in the custom annotations? E.g. it’s about being able to put custom sections in the text format. In the namse section there’s a name annotation, you can name more things that you’d otherwise be able to name in the name section. And it would be more true after this. Maybe it’s already taken into account int he custom annotation proposal.
TL: everything here already has names in the text format, e.g. data segment. The text format already has syntax where you can name a data segment or any of these other entities. So the annotations proposal isn’t necessary to use these names and round trip them. So I’m not familiar with the name annotation you mentioned. It doesn’t seem necessary, but I also wouldn’t anticipate any bad interactions.
YI: Curious because I recently touched this and now we have the tests for the name section,. So I wonder if this new addition should also go to those tests. The ordering of the proposals.
TL: yeah, adding support for these to existing name section tests sounds great.
PP: on the LLVM side, I think typical native toolchains produce symbol tables a little differently but that shouldn’t stop us. Also this is phase 2, not phase 4, so that shouldn’t block this.
YI: Nothing against advancing this.
TL: Doesn’t interact with linking at all. The LLVM symbols used in linking and debugging. This is useful for debugging in so far as it can give names to things when you disassemble the module. Independent from DWARF. Shouldn’t interact with anything else.
PP: yeah LLVM typically does what you do for linking symbols, this is parallel.
BT: is this enough to express all the names that are in the text format and round trip them?
AN: it does include all the names in the text format. Can you say more about round trip?
DS: as far as I know, yes - if not, it should
TL: actually one thing missing here is type names, which can be named (even in MVP linear text format). Those don’t appear here because they’ve been added to the GC proposal, since we assumed that GC would go to phase 4 before this. The GC proposal extends the name section with type names and field names. Field names are of course specific to GC, but type names are important for GC too. Actually one thing that’s missing for round tripping IIRC, if you define a function type, you’re allowed to give names to the params in the function type, there’s no way to round trip that yet. Nobody has proposed it.
BT: Fair enough, thanks
DS: Something we can possibly rectify if GC goes to Phase 4 and this proposal is still in 2 or 3
YI: With the name annotations proposal you can name parameters.
TL: That would be solved in the text format or the binary format as well? Right now IIRC you can name parameters in the text format but not in the binary. Double checking that now.
TL (chat): A note from the spec: "The optional identifier names for parameters in a function type only have documentation purpose. They cannot be referenced from anywhere."
DS: Any other comments on this proposal for phase 2. Definitely sounding like people are supportive. I think we can just do a unanimous consensus poll. If anyone has any objections for moving this proposal to phase 2, please speak up now.
no objections
DS: Sounds good to me. With that, that is everything on the agenda. Thanks everyone. Remember Deepti has sent out a form for the hybrid in-person meeting in October. So if you’re interested in coming to that, please fill that out so we can plan. Thanks, see you all in a couple of weeks.