On 9/30/2026 4:14 PM, Brian Cain wrote:
On 9/29/2026 3:28 PM, Brian Cain wrote:
On 9/29/2026 1:09 PM, Marco Liebel wrote:
On 26.09.2026 14:23, Brian Cain wrote:
Signed-off-by: Brian Cain <[email protected]>
---
target/hexagon/mmvec/hvx_ieee_fp.h | 2 +
target/hexagon/mmvec/macros.h | 2 +
target/hexagon/mmvec/hvx_ieee_fp.c | 15 ++++
target/hexagon/tag_rev_info.c.inc | 13 ++++
target/hexagon/imported/mmvec/encode_ext.def | 10 +++
target/hexagon/imported/mmvec/ext.idef | 74
++++++++++++++++++++
6 files changed, 116 insertions(+)
+ITERATOR_INSN_SHIFT_SLOT_FLT(16, vconv_h_hf_rnd,"Vd32.h=Vu32.hf:rnd",
+ "Vector conversion of hf16 format to int hw, round to nearest
even",
+ VdV.h[i] = float16_to_int16_scalbn(VuV.hf[i],
float_round_nearest_even, 0,
+ &env->hvx_fp_status))
+
I think there are two issues with vconv_h_hf_rnd. Because it's using
float16_to_int16_scalbn:
- It hard-codes nearest-even instead of using USR.FPRND.
This matches the defined semantics for rounding.
https://docs.qualcomm.com/doc/80-N2040-61/topic/hvx-floating-point.html#rounding-modes
"HVX floating point only supports IEEE-754 round-to-even mode."
Okay - as it turns out, Marco has explained to me that the statement
applies to the unqualified instructions. In fact, the explicit ":rnd"
instructions *do* consult USR round fp flags. I will fix this too.
Ugh - this thread has turned into a bit of a flip/flop/flip.
The text in the PRM regarding :rnd instructions was wrong, so we've
asked for a correction and will post an updated link to the PRM when
that happens. In the meantime, we've verified QEMU against the
instruction set simulator hexagon-sim that ships with the commercial
Hexagon SDK. That confirms the round-to-nearest-even behavior
originally implemented. The v2 series reflects that and adds tests to
show the rounding behavior independent of USR.
v2 posted:
https://lore.kernel.org/qemu-devel/[email protected]/
- It uses generic conversion, which returns INT16_MAX for negative
NaNs. Hexagon requires INT16_MIN.
I will fix this.
