Re: [PATCH 0/4] gdb: Display fp8 format for AArch64 registers

[Pedro Alves <pedro@palves.net>]

Hi!

On 2025-09-25 22:18, Ezra.Sitorus@arm.com wrote:
> From: Ezra Sitorus <ezra.sitorus@arm.com>
> 
> FP8 introduces 2 new formats: E4M3 and E5M2. This patch aims to add
> support for these types in gdb, and then display them in AArch64
> registers.
> 
> So far, this patch series only adds support for these in register printing.
> I've picked this, as opposed to printing fp8 variables because (as far
> as I'm aware) there is not enough DWARF information to help out with this.
> The __mfp8 type has the encoding type 7/unsigned. I'd like to hear any
> comments about this approach.

Is __mfp8 a real floating type supported by the compiler, or an opaque typedef?  

Some AMDGPUs have FP8 support, and there, Clang does not expose a real floating point
type for this.  Instead, we have __amd_fp8_storage_t type that is just a typedef to uint8_t.

From <https://gcc.gnu.org/pipermail/gcc-patches/2024-August/659261.html> I understand
that Aarch64's __mfp8 (and mfloat8_t) is the same.  Has that changed since?

Assuming it's still the same, since these types are really integers, making variables of
such types behave like real floating point variables would be incorrect, in the sense
that expressions involving them would behave differently in the actual source code compared
to typing them in GDB, like "print a + b" or "print c = 3.3", for example.

Since the "floatness" ends up being a presentation issue, for AMDGPU, we added support for
these types as gdb Python pretty printers instead.  We also added some gdb python functions
to manipulate them.  See:
  https://github.com/ROCm/ROCgdb/commit/ad1525387e2ae0a7e46d5b828967ab092c63ecfd

> 3/4: adds support for displaying these formats in certain AArch64 registers.

Is it really just display?  Doesn't the series allow writing to registers with "p \$v0.b.e4m3 = 3.3"
(where 3.3 is parsed as a double) or some such?  I suppose that might be OK if the type of the
register is a built-in GDB type with its own name that is not the same name as of the type the
compiler would use for a variable (__mfp8 / mfloat8_t).

What about expressions involving FP8 types, like addition, etc.  Doesn't that start working with
your series as well, if you start from one of those registers (or cast a number to the built-in
gdb type)?  Like "p \$v0.b.e4m3 + 3.3".

> 4/4: adds test cases for these register displays.

If it is possible to write to the register, and do arithmetic with it, I think we should have tests
for it.  Well, even if it isn't possible it would be good to test that too (to make sure it fails instead
of doing something bogus).

Another (related) detail that I think we should consider when it comes to expressions involving fp8 floats,
is that while the interchange format is the same between vendors, thanks to joint multi-vendor work
that lead to the OCP spec (https://www.opencompute.org/documents/ocp-8-bit-floating-point-specification-ofp8-revision-1-0-2023-12-01-pdf-1),
I believe ARM/Nvidia/AMD FP8 formats behave a bit differently from each other in terms of infinity/saturation/rounding
handling, things like that.  AMDGPUs even support two FP8 representations FP8-OCP and FP8-FNUZ, see:
  https://rocm.docs.amd.com/projects/HIP/en/latest/reference/low_fp_types.html

Are the AArch64 FP8s added here OCP?  I think it we are likely to end up with different versions
of these types in libiberty / gdb, so it'd be good to consider making that explicit in the names of
the floatformat types in libiberty as well as in the name of the gdb built-in types.

Thanks,
Pedro Alves