Skip to content

Latest commit

 

History

History
139 lines (88 loc) · 6.04 KB

CG-05-07.md

File metadata and controls

139 lines (88 loc) · 6.04 KB
Raw

WebAssembly logo

Agenda for the May 7th video call of WebAssembly's Community Group

  • Where: Virtual meeting
  • When: 2024-05-07, 16:00-17:00 UTC (2024-05-07, 9am-10am PDT, 18:00-19:00 CEST)
  • Location: link on W3C calendar or Google Calendar invitation

Registration

No registration is required for VC meetings. The meeting is open to CG members only.

Agenda items

  1. Opening
  2. Proposals and discussions
    1. Branch Hinting Update about new spec document for Code Metadata (Yuri Iozzelli, 15 minutes)
    2. FP16 proposal update (Ilya Rezvov, 45 minutes)
  3. Closure

Agenda items for future meetings

None

Meeting Notes

Attendees

  • Yuri Iozzellli
  • Linwei Shang
  • Jeff Charles
  • Robin Freyler
  • Chris Fallin
  • Yury Delendik
  • Paolo Severini
  • Nick Fitzgerald
  • Petr Penzin
  • Ben Visness
  • Ilya Rezvov
  • Adam Bratschi-Kaye
  • Conrad Watt
  • Oscar Spencer
  • Alex Crichton
  • Heejin Ahn
  • Deepti Gandluri
  • Thomas Lively
  • Chris Woods
  • Emanuel Ziegler
  • Bailey Hayes
  • Francis McCabe
  • Andrew Brown
  • Brendan Dahl
  • Jakob Kummerow
  • Zalim Bashorov
  • Sam Clegg
  • Daniel Lehmann
  • Adam Klein
  • Jpages
  • Jonchesterfield
  • Tal Garfinkel

Proposals and discussions

Branch Hinting Update about new spec document for Code Metadata (Yuri Iozzelli, 15 minutes)

YI presenting slides

CW: Who is currently consuming the branch-hinting hints? To do something in the engine?

YI: Currently V8 supports it and JSC supports it. There is some work in Firefox, I saw an open issue about some ambiguity, I don’t know what stage it’s at.

DS: Would it make sense to move the name section metadata into the appendix as well?

YI: here was some talk on github about it. There is also some new stuff added in the custom annotation proposal that could maybe go in some document like this. There wasn’t a real consensus. It kind of made sense that something very basic like the name section could stay in the appendix. This doc in particular is that metadata format, and the name section isn’t in that format but there could be something like it.

FP16 proposal update (Ilya Rezvov, 45 minutes)

IR Presenting [TODO Slides]

[slide: instructions] CW: I’m much happier with the proposal in this state, I think it makes a lot of sense under SIMD. In the previous version we already had i8, i16 SIMD vectors but didn’t try to add those scalar types either.

AB: what kind of value do you splat in f16x8_splat?

IR: You splat f32 to f16 lanes with conversion. Also we don’t need any specific load and store for f16 because we have load_lane, store_lane 16 so there’s no need to do extra

PP: Wouldn’t you also need to splat f16 too?

IR: you can load lane right now, splat lane from memory, it doesn’t care if it’s f16, i16 or whatever.

AC [chat]: Is there a good sense of scale, at this time, for how large the implementation is for platforms that don’t have native support for f16?

IR: I have numbers, after this slide.

PP: For FMA, it depends on what we have on hardware, is this available on hardware, and do they all do FMA the same way?

IR: unfortunately I haven’t been able to test AVX512.

PP:You’re not supporting dot products right? It has the same rounding issues

IR: dot products so far are supported only for integers

PP: we looked at bfloat dot, but that was the problem, that they rounded differently on different platforms.

IR: We’re in a better position here because F32 & F16 were around for some time, F16 is more or less consistent, or we don’t have hardware support - its not similar to the overflow/underflow conditions for previous instructions - we will probably need two conversion operations with/without overflow for faster conversions

PP: on the NaNs: we have a canonical NaN idea, the question is why would you need that in FP16 space. The original motivation was to do nanboxing, and now we have only a SIMD proposal, nobody will store a pointer in a 16, this could be exempt from the canonicalization rules

CW: Is the NaN non-determinism here same or different from scalar operations, or can this be more ambitious?

PP: If you have hardware support then yes, youd expect that x86 would have a different sign but

CW: is the nondeterminism in the sign bit something we already allow in scalars?

PP: I got this wrong, question is if you have a canonical payload, and you operate on two of them, you should get a canonical payload back. With the baseline spec you get a 2-3x instruction bloat in codegen. Here you might make the expensive more costly on x86, because f16 codegen is going to be more expensive

IR: I think it makes sense to be less restrictive here on determinism here

CW: we should carefully write up how it would be different from scalar nondterminsim so we can see how it comes out

PP: it should be straightforward

IR slide, implementation feedback

CW: for the analogous existing f32 and f64 SIMD instructions, do they all round to even, and do they have similar problems on x86?

IR: they are round to even, and they are natively supported, the only problem is with double transition, when you go from 64 to 32 and 32 to 16, there is no such issue for just 64 and 32. There’s no direct conversion from 64 to 16 in F16C.

CW: I’m not asking you to justify Intel’s decision, but asking if there’s more info :)

IR: yeah there’s no issue with just 64 and 32, no 2-hop conversion so, double-rounding isn’t a problem. It’s a similar issue to FMA. it’s a good idea maybe to move f64 to f16 conversion to relaxed SIMD

CW: Should be fine in principle, but we should document it carefully

IR: yeah, it’s a good idea. I assume most of the use cases don’t care about that rounding, especially e.g. for ML workloads.

Closure