Execution semantics

[ngzhian]

Preview at https://www.ngzhian.com/simd/core/exec/instructions.html#simd-instructions.

[ngzhian]

@binji I'm still working on shuffle, swizzle, load splat and load extends, the rest of the ops are mostly done, definitely still needs cleanup. Hoping you can take a preliminary look.

[ngzhian]

I left some review notes (numbered based on suggested ordering to look at) to highlight bigger changes or extensions to existing definition.

[binji]

Did a pass on it, I really like extending the numerics, makes it much nicer to read IMO

[rossberg]

Some preliminary comments, haven't read all of exec/instructions yet.

[ngzhian]

@rossberg Thanks for the careful review. I have resolved all the minor issues. Left a couple of responses and questions for you. And apologies for not doing the recent changes at one go. I missed that there was a "Show X hidden conversations" button that had a couple of your review notes, and so I didn't fix those issues during my first go.

[ngzhian]

As a checklist, the remaining open comments are (listing here since some of the comments are hidden):

• argument to narrow_u being signed Execution semantics #340 (comment)
• narrow v.s. inarrow Execution semantics #340 (comment)

[rossberg]

Great! Thanks for bearing with me.

[rossberg]

Oops, I just noticed that there's a related issue with vtrunc and vconvert, whose execution does not map to that of a regular op either, because it involves two shapes. I think you'll need to introduce a vcvtop category and handle that separately. (Also, they are currently included in vbinop, which does not even seem correct for typing).

Feel free to fix that in a separate PR, if you prefer.

[ngzhian]

I think you'll need to introduce a vcvtop category and handle that separately.

Good catch, thanks. Added a new production, vcvtop, which has its own validation and execution.

The way I'm writing them now relies on this new note on execution/numerics: https://github.com/WebAssembly/simd/pull/340/files#diff-14d634364829defe70ba02a1ed0075266fce32b208b681eb5a812e96104e2bf9R41
My intention is that this also applies to the conversion operators, is that a correct assumption? Or should I clarify that section with an example showing how conversion operators work when given a list of inputs?

[rossberg]

Thanks. LGTM modulo comment.

Yes, the note should suffice. If you want to emphasise that it applies to heterogeneously typed ops like conversions as well, you could replace the simple fabs example that follows with convert.