First-class F16 type and scalar operation

[SPY]

The introduction of the proposal included first-class F16 scalar value type and operations for it.
During exploratory implementation in V8 I discovered it is pretty costly to bring it to V8: there is no instances of 16-bit optional registers/operations, so register allocator, memory allocator and others need significant refactoring. Also, there is no interest in scalar operations from potential users I discussed the proposal with.
Also, during the discussion at CG the same question was raised in chat: "Could we have F16 SIMD shapes without having an F16 scalar type? Similar to i8 and i16 SIMD shapes without i8 and i16 scalar types in the spec so far."
I think I can answer that question now: we don't need them until some concrete and persuading use cases are demonstrated.

Opening that issue for tracking that question.

[sjrd]

FWIW, it looks like Java is going to add actual F16 scalar operations. There is a Float16 class in an incubator package will all those bells and whistles:
https://docs.oracle.com/en/java/javase/24/docs/api/jdk.incubator.vector/jdk/incubator/vector/Float16.html

If we're not going to have an f16 type and related operations, I suggest we at least provide an explicit demoting operation:

• f32.demote16_f32: [f32] -> [f32]
  explicitly demotes an f32 to an f16, applying the usual rounding operation (round-ties-to-even), and immediately promote it again to an f32

With this instruction, we can accurately implement all the basic IEEE F16 operations using F32 operations each immediately followed by f32.demote16_f32. For example, an addition would be (f32.demote16_f32 (f32.add <a> <b>)). Since the precision of f16 is $p = 10$, and since that of f32 is $24 \geq 2p + 2$, the paper When is double rounding innocuous proves that this strategy is correct for Addion, Subtraction, Multiplication, Division and Square Root.

It is not enough, AFAICT, to implement the f64 -> f16 conversion. However, that should be a fairly unusual operation. We could provide it as f32.demote16_f64 anyway, or let the toolchains deal with it.