[PATCH v2] Support Intel AVX10.2 BF16 instructions

[Jan Beulich]

On 31.10.2024 08:54, Jiang, Haochen wrote:
> This is the info I get from my colleagues:
> 
> For VSCALEFPBF16, the reason why it doesn't include NE in mnemonic is that it
> Is actually not a NE inst. It is always exact since underflow is FTZed.
> 
> However, the confusion here is that VSCALEFPD/S/H got this: "The overflow and
> underflow responses are dependent on the rounding mode (for IEEE-compliant
> rounding), as well as on other settings in MXCSR (exception mask bits), and on
> the SAE bit." I suppose it is not the normal understanding on rounding. This has
> made others got the expression that SCALEF insts got different roundings,
> causing the mnemonic of VSCALEFPBF16 confusing.

I don't think the rounding understanding is very far from "normal". It's still
a multiplication that is (effectively) being carried out, with the usual effect
that a (normal) multiplication would also have. I could kind of agree the BF16
form is different for underflows (flushing to zero, albeit doesn't even that
still fit "round to nearest even", at least together with FTZ/DAZ?); for
overflows it'll still be normal rounding behavior though (resulting in infinity
iiuc).

Imo what the SDM tries to emphasize is that depending on (just) the sign of the
scale value it can only be one of overflow or underflow.

> The discussion on whether to add NE is still ongoing.

I see.

> For VRNDSCALENEPBF16, the NE should be kept after I read the SDM. The original
> VRNDSCALEPS/D/H actually uses imm8[1:0] as commonly understanding rounding
> control, 00 as round nearest ever, 01 as round down, 10 as round up and 11 as
> truncate. This also reflects in how we emulate in SDM introduction on this inst, for
> PD version, we got:
> 
> ROUND(x) = 2^(-M)*Round_to_INT(x*2^M, round_ctrl),
> round_ctrl = imm[3:0];
> M=imm[7:4];
> 
> However, on BF16, the rounding is always RNE, you could see the rounding is restricted
> to RNE in emulation:
> 
> ROUND(x) = 2^(-M)*Round_to_INT(x*2^M, RNE), M=imm[7:4];
> 
> That is why NE appears in mnemonic.

Interesting. The insn's description is actually self-inconsistent right now: It
first says "Round the bfloat16 floating-point values in the source operand by the
rounding mode specified in the immediate operand and places the result in the
destination operand." (Note in particular the use of "rounding _mode_".) Only
later it is (kind of indirectly) said that the low 4 bits of the immediate aren't
used: "RNE rounding mode is used." Followed by a cryptic partial sentence "the
imm8[7:4] value)."

Considering this somewhat peculiar difference I further wonder whether the
assembler wouldn't better be made warn if the low 4 bits weren't all clear.

> Also in the discussion, maybe best way would be to explicitly state globally in the doc
> that all BF16 ISA obey the following rules: Disregard MXCSR (i.e. not reading it, neither
> updating it), implicit SAE, DAZ, FTZ and RNE(when not exact).

Plus actually make explicit what "NE" stands for.

Jan