Recently I have reviewed the latest revision of the proposal, and I have several remarks:
Concerning the vector combine instructions that operate on vector halves (e.g. vec.f32.concat_lower_lower) - are variants for each element type really necessary? After all, the size of half a vector is independent of the element type, unless the idea is to accommodate the option to set the vector length dynamically, which the current specification allows to do for each element type independently.
Is it intentional that there is no vector reverse operation for 8-bit elements?
Similarly for duplicate even lanes?
As for both left and right shifts by scalar - is the shift amount meant to be unsigned? Otherwise the pseudocode doesn't make sense for negative shift values - it would access the input vector out-of-bounds.
The concat_upper_lower operation description (but not the pseudocode) is wrong, i.e. it corresponds to concat_lower_upper.
Not a shuffle operation, but I don't want to open a separate issue just for it - the prototypes of the square root operation are binary functions.
Recently I have reviewed the latest revision of the proposal, and I have several remarks:
vec.f32.concat_lower_lower) - are variants for each element type really necessary? After all, the size of half a vector is independent of the element type, unless the idea is to accommodate the option to set the vector length dynamically, which the current specification allows to do for each element type independently.concat_upper_loweroperation description (but not the pseudocode) is wrong, i.e. it corresponds toconcat_lower_upper.