Select 128 can only be select_t

[andreaTP]

This is a fix on top of the recently merged #1899 .

From the spec:

If missing, the operands must be of numeric type.

With numtype:

Vector Types are not Number Types, hence the select type should be explicitly defined.

[andreaTP]

cc. @Zzzabiyaka

[rossberg]

Note that this is just non-normative text describing the purpose of the instruction. It apparently wasn't updated by the SIMD proposal.

The normative specification of validation for select is here and allows vector types to be omitted as well.

I updated the informal description.

[andreaTP]

@rossberg thanks for the explanation.

How do you know if SELECT(without explicitly defined type) should operate on Numbers or on Vector Types?

We have the same question for other opcodes like LOCAL_GET/LOCAL_SET but in that case the type is stored in the function signature.

From an initial look, the only way to infer the correct type of SELECT is to do it in the validation algorithm or keeping the information around at runtime, but this is the first time we have to do something like this.

Just to explicitly state the problem, in the Chicory interpreter we use a fully untyped long array as Stack and we store Vector types using 2 slots.

In this situation we don't know how many values to pop and this is the only opcode where it is, non-decidable(if I understand it correctly) without an additional type inference step.

[rossberg]

@andreaTP, well, semantically, it does not matter. And a jit will know the type. An interpreter using heterogeneous representations, however, may have to do some extra work, like storing type information from validation in a side table.

That's certainly annoying, but that problem is neither specific to vector types (i32 and i64 may already be of different size), nor to the select instruction (e.g., consider the drop instruction). So while I was never in favour of expanding the legacy form to vector types personally, I don't think it introduced any novel problems.

[andreaTP]

Thanks again for the prompt answer.

I don't think it introduced any novel problems.

Agreed, I'm going to close this one.

[titzer]

From an initial look, the only way to infer the correct type of SELECT is to do it in the validation algorithm or keeping the information around at runtime, but this is the first time we have to do something like this.

FWIW drop is also polymorphic in the same way.

[andreaTP]

Thanks 👍