-
Notifications
You must be signed in to change notification settings - Fork 43
Names of load instructions #297
Comments
I like that this is more explicit about the load size. It seems like it's a win for the splat/zero cases, but the extend case is less clear, IMO. Not sure quite how to improve, though. |
Could we balance spec simplicity with readability by having the load-extends be Edit: In more detail, perhaps |
In the basic numeric load instructions we don't spell out "extend", so wouldn't the most symmetric names simply be |
Good point, so the names will be:
|
Those look great to me! |
Yes, these look pretty good to me too. I still think the extend instructions are not super clear, but that's OK. (still not as bad as |
Following suggestions in WebAssembly#297, renaming load splats to something more consistent.
The names are still pre WebAssembly#297, once that's finalize I can fix this up (after the sync WebAssembly#323). With this change, test/core/run.py passes on all test cases in simd/.
Following suggestions in WebAssembly#297, renaming load splats and load extends to something more consistent. Fixed WebAssembly#297.
Follow up to WebAssembly#297 for renaming the instructions in binary and text sections in the spec.
These instructions previously used prefixes like v8x16 to signify that they were agnostic between float and int interpretations. We renamed these instructions to remove this form of prefix in WebAssembly/simd#297 and WebAssembly/simd#316 and this commit brings the names in LLVM up to date. Differential Revision: https://reviews.llvm.org/D93722
I would like to discuss the names of load instructions (this came up in #237 and #271).
Currently, we have:
v128.load
v8x16.load_splat
,v16x8.load_splat
,v32x4.load_splat
,v64x2.load_splat
i16x8.load8x8_s
,i16x8.load8x8_u
,i32x4.load16x4_s
,i32x4.load16x4_u
,i64x2.load32x2_s
,i64x2.load32x2_u
v128.load32_zero
,v128.load64_zero
Some issues:
v128
v.s.v8x16
v.s.i8x16
.load8x8_s
), in some cases it has the number of bytes loaded (inload32_zero
), and sometimes it's just a word (splat
).A more consistent naming convention will be:
v128.load
prefix, this is the return type, it makes it clear that all the loads return av128
i32.load8_s
)splat
,extend
,zero
With this convention, all the loads now look like:
v128.load
v128.load8_splat
,v128.load16_splat
,v128.load32_splat
,v128.load64_splat
load extends,v128.load64_extend8x8_s
,v128.load64_extend8x8_u
,v128.load64_extend16x4_s
,v128.load64_extend16x4_u
,v128.load64_extend32x2_s
,v128.load64_extend32x2_s
v128.load8x8_s
,v128.load8x8_u
,v128.load16x4_s
,v128.load16x4_u
,v128.load32x2_s
,v128.load32x2_s
v128.load32_zero
,v128.load64_zero
(The load extends are a bit wordy, maybe we can come up with a better name.)cc @tlively @Maratyszcza
The text was updated successfully, but these errors were encountered: