Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upAdd validation for SIMD instructions #327
Conversation
| \AVGRU ~|~ | ||
| \TRUNC ~|~ | ||
| \CONVERT \\ | ||
| \production{ternary operator} & \vsternop &::=& \SHUFFLE \\ |
This comment has been minimized.
This comment has been minimized.
rossberg
Aug 28, 2020
Member
Why is this vsternop while the others are vunop, vbinop (without the s)? Are vsunop, vsbinop defined somewhere else? (They appear in validation rules.)
This comment has been minimized.
This comment has been minimized.
ngzhian
Aug 28, 2020
Author
Member
My horrible naming convention is:
- vs* is all the shape-agnostic instructions, like v128.and
- vi* is all the int-shape instructions, like i32x4.add
- vf* is all the float-shape instructions, like f32x4.sqrt
- v* is union of vi* and vf*
vsunop and vsbinop are defined in the production for instructions above, they aren't grouped as part of this "Conventions" section.
I decided to not group them together becase the validation instructions have 2 different matches, t.op which is for vs* family of instructions, and vxx.op, for the vi*, vf*, v* family.(since t matches v128 and vxx matches all the shapes.)
|
Btw, as a heads-up, I'm vanishing off the grid for the next 2 weeks, so this has to be my last review until after. |
|
No problem, have a great time! |
ngzhian commentedAug 26, 2020
Preview at https://www.ngzhian.com/simd/core/valid/instructions.html
There are a bunch of todos:
t.constis defined under "numeric instructions", which already covers v128. Do we need to define v128.const again?packedas a way to mapi8andi16as they appear in the instruction names toi32(and the other types to themselves), does that definition look okay?