* [PATCH 1/4] libiberty: Add fp8 float formats
2025-09-25 21:18 [PATCH 0/4] gdb: Display fp8 format for AArch64 registers Ezra.Sitorus
@ 2025-09-25 21:18 ` Ezra.Sitorus
2025-09-25 21:18 ` [PATCH] gdb: Add support for fp8 formats Ezra.Sitorus
` (3 subsequent siblings)
4 siblings, 0 replies; 9+ messages in thread
From: Ezra.Sitorus @ 2025-09-25 21:18 UTC (permalink / raw)
To: gdb-patches; +Cc: eliz, luis.machado.foss, Ezra Sitorus
From: Ezra Sitorus <ezra.sitorus@arm.com>
Add the 8 bit floating point formats E5M2 and E4M3 to libiberty.
E5M2 follows the IEEE convention on special values while E4M3 increases
the dynamic range by reducing the number of values. Note that this patch
only adds the values required for struct floatformat - another patch is
sent in gdb to determine the output of these values.
Technical information on FP8 can be found here:
https://arxiv.org/abs/2209.05433
The gcc patch is here: https://sourceware.org/pipermail/gcc-patches/2025-September/696165.html
---
libiberty/floatformat.c | 32 ++++++++++++++++++++++++++++++++
1 file changed, 32 insertions(+)
diff --git a/libiberty/floatformat.c b/libiberty/floatformat.c
index fe82e019cc9..96ab956aef0 100644
--- a/libiberty/floatformat.c
+++ b/libiberty/floatformat.c
@@ -269,6 +269,38 @@ const struct floatformat floatformat_arm_ext_littlebyte_bigword =
floatformat_always_valid,
NULL
};
+const struct floatformat floatformat_fp8_e5m2_big =
+{
+ floatformat_big, 8, 0, 1, 5, 15, 31, 6, 2,
+ floatformat_intbit_no,
+ "floatformat_fp8_e5m2_big",
+ floatformat_always_valid,
+ NULL
+};
+const struct floatformat floatformat_fp8_e5m2_little =
+{
+ floatformat_little, 8, 0, 1, 5, 15, 31, 6, 2,
+ floatformat_intbit_no,
+ "floatformat_fp8_e5m2_little",
+ floatformat_always_valid,
+ NULL
+};
+const struct floatformat floatformat_fp8_e4m3_big =
+{
+ floatformat_big, 8, 0, 1, 4, 7, 15, 5, 3,
+ floatformat_intbit_no,
+ "floatformat_fp8_e4m3_big",
+ floatformat_always_valid,
+ NULL
+};
+const struct floatformat floatformat_fp8_e4m3_little =
+{
+ floatformat_little, 8, 0, 1, 4, 7, 15, 5, 3,
+ floatformat_intbit_no,
+ "floatformat_fp8_e4m3_little",
+ floatformat_always_valid,
+ NULL
+};
const struct floatformat floatformat_ia64_spill_big =
{
floatformat_big, 128, 0, 1, 17, 65535, 0x1ffff, 18, 64,
--
2.45.2
^ permalink raw reply [flat|nested] 9+ messages in thread* [PATCH] gdb: Add support for fp8 formats
2025-09-25 21:18 [PATCH 0/4] gdb: Display fp8 format for AArch64 registers Ezra.Sitorus
2025-09-25 21:18 ` [PATCH 1/4] libiberty: Add fp8 float formats Ezra.Sitorus
@ 2025-09-25 21:18 ` Ezra.Sitorus
2025-09-25 21:18 ` [PATCH 3/4] gdb/aarch64: Display fp8 formats in registers Ezra.Sitorus
` (2 subsequent siblings)
4 siblings, 0 replies; 9+ messages in thread
From: Ezra.Sitorus @ 2025-09-25 21:18 UTC (permalink / raw)
To: gdb-patches; +Cc: eliz, luis.machado.foss, Ezra Sitorus
From: Ezra Sitorus <ezra.sitorus@arm.com>
FP8 introduces 2 new formats: E5M2 and E4M3. E5M2 follows IEEE
conventions for exponents and special values. On the other hand, E4M3
increases the dynamic range by having fewer special values - there is no
infinity, and only one encoding for NaN. This has been accounted for in
gdb/target-float.c: floatformat_classify and from_target.
One particular thing I would like to highlight is that since e4m3 has
only 1 NaN encoding - all ones - this will be printed as nan(0x7). You
can see this in the test cases later. I would like to ask if there is a
better way of handling this?
More information about FP8 can be found in the technical paper here:
https://arxiv.org/abs/2209.05433
---
gdb/gdbtypes.c | 8 ++++++++
gdb/gdbtypes.h | 2 ++
gdb/target-descriptions.c | 10 ++++++++++
gdb/target-float.c | 12 +++++++++++-
gdbsupport/tdesc.cc | 4 +++-
gdbsupport/tdesc.h | 2 ++
include/floatformat.h | 5 +++++
7 files changed, 41 insertions(+), 2 deletions(-)
diff --git a/gdb/gdbtypes.c b/gdb/gdbtypes.c
index 24e6d0bf8f5..f07c259e25b 100644
--- a/gdb/gdbtypes.c
+++ b/gdb/gdbtypes.c
@@ -79,6 +79,14 @@ const struct rank NS_INTEGER_POINTER_CONVERSION_BADNESS = {3,0};
const struct rank VARARG_BADNESS = {4, 0};
/* Floatformat pairs. */
+const struct floatformat *floatformats_fp8_e5m2[BFD_ENDIAN_UNKNOWN] = {
+ &floatformat_fp8_e5m2_big,
+ &floatformat_fp8_e5m2_little
+};
+const struct floatformat *floatformats_fp8_e4m3[BFD_ENDIAN_UNKNOWN] = {
+ &floatformat_fp8_e4m3_big,
+ &floatformat_fp8_e4m3_little
+};
const struct floatformat *floatformats_ieee_half[BFD_ENDIAN_UNKNOWN] = {
&floatformat_ieee_half_big,
&floatformat_ieee_half_little
diff --git a/gdb/gdbtypes.h b/gdb/gdbtypes.h
index 75c77b3a90c..6faffb4217d 100644
--- a/gdb/gdbtypes.h
+++ b/gdb/gdbtypes.h
@@ -2209,6 +2209,8 @@ extern const struct floatformat *floatformats_ieee_double_littlebyte_bigword[BFD
extern const struct floatformat *floatformats_i387_ext[BFD_ENDIAN_UNKNOWN];
extern const struct floatformat *floatformats_m68881_ext[BFD_ENDIAN_UNKNOWN];
extern const struct floatformat *floatformats_arm_ext[BFD_ENDIAN_UNKNOWN];
+extern const struct floatformat *floatformats_fp8_e5m2[BFD_ENDIAN_UNKNOWN];
+extern const struct floatformat *floatformats_fp8_e4m3[BFD_ENDIAN_UNKNOWN];
extern const struct floatformat *floatformats_ia64_spill[BFD_ENDIAN_UNKNOWN];
extern const struct floatformat *floatformats_vax_f[BFD_ENDIAN_UNKNOWN];
extern const struct floatformat *floatformats_vax_d[BFD_ENDIAN_UNKNOWN];
diff --git a/gdb/target-descriptions.c b/gdb/target-descriptions.c
index dc5fbacfebd..9f9cc9ad95f 100644
--- a/gdb/target-descriptions.c
+++ b/gdb/target-descriptions.c
@@ -147,6 +147,16 @@ make_gdb_type (struct gdbarch *gdbarch, struct tdesc_type *ttype)
m_type = init_float_type (alloc, -1, "builtin_type_bfloat16",
floatformats_bfloat16);
return;
+
+ case TDESC_TYPE_FP8_E5M2:
+ m_type = init_float_type (alloc, -1, "builtin_type_fp8_e5m2",
+ floatformats_fp8_e5m2);
+ return;
+
+ case TDESC_TYPE_FP8_E4M3:
+ m_type = init_float_type (alloc, -1, "builtin_type_fp8_e4m3",
+ floatformats_fp8_e4m3);
+ return;
}
internal_error ("Type \"%s\" has an unknown kind %d",
diff --git a/gdb/target-float.c b/gdb/target-float.c
index 9b0376f2909..d0068e9f453 100644
--- a/gdb/target-float.c
+++ b/gdb/target-float.c
@@ -396,6 +396,12 @@ floatformat_classify (const struct floatformat *fmt,
if (exponent == fmt->exp_nan)
{
+ if (fmt->totalsize == 8 && fmt->exp_len == 4)
+ {
+ if ((mant & 0b111) == 0b111)
+ return float_nan;
+ return float_normal;
+ }
if (mant_zero)
return float_infinite;
else
@@ -1287,7 +1293,11 @@ mpfr_float_ops::from_target (const struct floatformat *fmt,
mant_off = fmt->man_start;
mpfr_set_zero (to.val, 0);
- special_exponent = exponent == 0 || exponent == fmt->exp_nan;
+ /* If format is FP8 E4M3, then we handle the case of NaN above, and there is
+ no inf. */
+ special_exponent = (exponent == 0)
+ || (!(fmt->totalsize == 8 && fmt->exp_len == 4)
+ && (exponent == fmt->exp_nan));
/* Don't bias NaNs. Use minimum exponent for denorms. For
simplicity, we don't check for zero as the exponent doesn't matter.
diff --git a/gdbsupport/tdesc.cc b/gdbsupport/tdesc.cc
index ed92c864732..2b029484e51 100644
--- a/gdbsupport/tdesc.cc
+++ b/gdbsupport/tdesc.cc
@@ -54,7 +54,9 @@ static tdesc_type_builtin tdesc_predefined_types[] =
{ "ieee_double", TDESC_TYPE_IEEE_DOUBLE },
{ "arm_fpa_ext", TDESC_TYPE_ARM_FPA_EXT },
{ "i387_ext", TDESC_TYPE_I387_EXT },
- { "bfloat16", TDESC_TYPE_BFLOAT16 }
+ { "bfloat16", TDESC_TYPE_BFLOAT16 },
+ { "fp8_e5m2", TDESC_TYPE_FP8_E5M2 },
+ { "fp8_e4m3", TDESC_TYPE_FP8_E4M3 }
};
void tdesc_feature::accept (tdesc_element_visitor &v) const
diff --git a/gdbsupport/tdesc.h b/gdbsupport/tdesc.h
index 6bf66ad3dcd..f898f49647e 100644
--- a/gdbsupport/tdesc.h
+++ b/gdbsupport/tdesc.h
@@ -176,6 +176,8 @@ enum tdesc_type_kind
TDESC_TYPE_ARM_FPA_EXT,
TDESC_TYPE_I387_EXT,
TDESC_TYPE_BFLOAT16,
+ TDESC_TYPE_FP8_E5M2,
+ TDESC_TYPE_FP8_E4M3,
/* Types defined by a target feature. */
TDESC_TYPE_VECTOR,
diff --git a/include/floatformat.h b/include/floatformat.h
index b65968a8755..dadb5a217aa 100644
--- a/include/floatformat.h
+++ b/include/floatformat.h
@@ -136,6 +136,11 @@ extern const struct floatformat floatformat_ibm_long_double_little;
/* bfloat16. */
extern const struct floatformat floatformat_bfloat16_big;
extern const struct floatformat floatformat_bfloat16_little;
+/* fp8. */
+extern const struct floatformat floatformat_fp8_e5m2_big;
+extern const struct floatformat floatformat_fp8_e5m2_little;
+extern const struct floatformat floatformat_fp8_e4m3_big;
+extern const struct floatformat floatformat_fp8_e4m3_little;
/* Convert from FMT to a double.
FROM is the address of the extended float.
--
2.45.2
^ permalink raw reply [flat|nested] 9+ messages in thread* [PATCH 3/4] gdb/aarch64: Display fp8 formats in registers
2025-09-25 21:18 [PATCH 0/4] gdb: Display fp8 format for AArch64 registers Ezra.Sitorus
2025-09-25 21:18 ` [PATCH 1/4] libiberty: Add fp8 float formats Ezra.Sitorus
2025-09-25 21:18 ` [PATCH] gdb: Add support for fp8 formats Ezra.Sitorus
@ 2025-09-25 21:18 ` Ezra.Sitorus
2025-10-11 13:10 ` Luis
2025-09-25 21:18 ` [PATCH 4/4] gdb/aarch64: Tests for verifying fp8 register formats Ezra.Sitorus
2025-09-29 17:55 ` [PATCH 0/4] gdb: Display fp8 format for AArch64 registers Pedro Alves
4 siblings, 1 reply; 9+ messages in thread
From: Ezra.Sitorus @ 2025-09-25 21:18 UTC (permalink / raw)
To: gdb-patches; +Cc: eliz, luis.machado.foss, Ezra Sitorus
From: Ezra Sitorus <ezra.sitorus@arm.com>
Display fp8 formats for AArch64 vector/float registers. On a system
without SVE, the V register and B-pseudo registers have the new
e5m2/e4m3 formats. If it has SVE, then the Z registers, V and B pseudo
registers get the new e5m2/e4m3 formats.
---
gdb/aarch64-tdep.c | 41 ++++++++++++++++++++++++++++++++++++
gdb/aarch64-tdep.h | 4 ++++
gdb/features/aarch64-fpu.c | 10 +++++++++
gdb/features/aarch64-fpu.xml | 4 ++++
gdb/features/aarch64-sve.c | 10 +++++++++
5 files changed, 69 insertions(+)
diff --git a/gdb/aarch64-tdep.c b/gdb/aarch64-tdep.c
index 500ac77d75a..8e71a75efbb 100644
--- a/gdb/aarch64-tdep.c
+++ b/gdb/aarch64-tdep.c
@@ -2106,6 +2106,40 @@ aarch64_frame_align (struct gdbarch *gdbarch, CORE_ADDR sp)
return sp & ~(CORE_ADDR) 15;
}
+/* Return the type for FP8 E5M2 format. */
+
+static struct type *
+aarch64_fp8_e5m2_type (struct gdbarch *gdbarch)
+{
+ aarch64_gdbarch_tdep *tdep = gdbarch_tdep<aarch64_gdbarch_tdep> (gdbarch);
+
+ if (!tdep->fp8_e5m2_type)
+ {
+ type_allocator alloc (gdbarch);
+ tdep->fp8_e5m2_type = init_float_type (
+ alloc, -1, "builtin_type_fp8_e5m2", floatformats_fp8_e5m2);
+ }
+
+ return tdep->fp8_e5m2_type;
+}
+
+/* Return the type for FP8 E4M3 format. */
+
+static struct type *
+aarch64_fp8_e4m3_type (struct gdbarch *gdbarch)
+{
+ aarch64_gdbarch_tdep *tdep = gdbarch_tdep<aarch64_gdbarch_tdep> (gdbarch);
+
+ if (!tdep->fp8_e4m3_type)
+ {
+ type_allocator alloc (gdbarch);
+ tdep->fp8_e4m3_type = init_float_type (
+ alloc, -1, "builtin_type_fp8_e4m3", floatformats_fp8_e4m3);
+ }
+
+ return tdep->fp8_e4m3_type;
+}
+
/* Return the type for an AdvSISD Q register. */
static struct type *
@@ -2247,6 +2281,9 @@ aarch64_vnb_type (struct gdbarch *gdbarch)
elem = builtin_type (gdbarch)->builtin_int8;
append_composite_type_field (t, "s", elem);
+ append_composite_type_field (t, "e5m2", aarch64_fp8_e5m2_type (gdbarch));
+ append_composite_type_field (t, "e4m3", aarch64_fp8_e4m3_type (gdbarch));
+
tdep->vnb_type = t;
}
@@ -2516,6 +2553,10 @@ aarch64_vnv_type (struct gdbarch *gdbarch)
init_vector_type (bt->builtin_uint8, 16));
append_composite_type_field (sub, "s",
init_vector_type (bt->builtin_int8, 16));
+ append_composite_type_field (sub, "e5m2",
+ init_vector_type (aarch64_fp8_e5m2_type (gdbarch), 16));
+ append_composite_type_field (sub, "e4m3",
+ init_vector_type (aarch64_fp8_e4m3_type (gdbarch), 16));
append_composite_type_field (t, "b", sub);
sub = arch_composite_type (gdbarch, "__gdb_builtin_type_vnq",
diff --git a/gdb/aarch64-tdep.h b/gdb/aarch64-tdep.h
index 99e7d26ce4a..d9f44f1c15c 100644
--- a/gdb/aarch64-tdep.h
+++ b/gdb/aarch64-tdep.h
@@ -93,6 +93,10 @@ struct aarch64_gdbarch_tdep : gdbarch_tdep_base
struct type *sme_tile_slice_type_h = nullptr;
struct type *sme_tile_slice_type_b = nullptr;
+ /* Types for FP8 formats. */
+ struct type *fp8_e5m2_type = nullptr;
+ struct type *fp8_e4m3_type = nullptr;
+
/* Vector of names for SME pseudo-registers. The number of elements is
different for each distinct svl value. */
std::vector<std::string> sme_pseudo_names;
diff --git a/gdb/features/aarch64-fpu.c b/gdb/features/aarch64-fpu.c
index 27e75524cfe..13825c74640 100644
--- a/gdb/features/aarch64-fpu.c
+++ b/gdb/features/aarch64-fpu.c
@@ -46,6 +46,12 @@ create_feature_aarch64_fpu (struct target_desc *result, long regnum)
element_type = tdesc_named_type (feature, "int8");
tdesc_create_vector (feature, "v16i", element_type, 16);
+ element_type = tdesc_named_type (feature, "fp8_e5m2");
+ tdesc_create_vector (feature, "v16fp8e5m2", element_type, 16);
+
+ element_type = tdesc_named_type (feature, "fp8_e4m3");
+ tdesc_create_vector (feature, "v16fp8e4m3", element_type, 16);
+
element_type = tdesc_named_type (feature, "uint128");
tdesc_create_vector (feature, "v1u", element_type, 1);
@@ -85,6 +91,10 @@ create_feature_aarch64_fpu (struct target_desc *result, long regnum)
tdesc_add_field (type_with_fields, "u", field_type);
field_type = tdesc_named_type (feature, "v16i");
tdesc_add_field (type_with_fields, "s", field_type);
+ field_type = tdesc_named_type (feature, "v16fp8e5m2");
+ tdesc_add_field (type_with_fields, "e5m2", field_type);
+ field_type = tdesc_named_type (feature, "v16fp8e4m3");
+ tdesc_add_field (type_with_fields, "e4m3", field_type);
type_with_fields = tdesc_create_union (feature, "vnq");
field_type = tdesc_named_type (feature, "v1u");
diff --git a/gdb/features/aarch64-fpu.xml b/gdb/features/aarch64-fpu.xml
index 509824f55fb..26e292ee625 100644
--- a/gdb/features/aarch64-fpu.xml
+++ b/gdb/features/aarch64-fpu.xml
@@ -20,6 +20,8 @@
<vector id="v8bf16" type="bfloat16" count="8"/>
<vector id="v16u" type="uint8" count="16"/>
<vector id="v16i" type="int8" count="16"/>
+ <vector id="v16fp8e5m2" type="fp8_e5m2" count="16"/>
+ <vector id="v16fp8e4m3" type="fp8_e4m3" count="16"/>
<vector id="v1u" type="uint128" count="1"/>
<vector id="v1i" type="int128" count="1"/>
<union id="vnd">
@@ -41,6 +43,8 @@
<union id="vnb">
<field name="u" type="v16u"/>
<field name="s" type="v16i"/>
+ <field name="e5m2" type="v16fp8e5m2"/>
+ <field name="e4m3" type="v16fp8e4m3"/>
</union>
<union id="vnq">
<field name="u" type="v1u"/>
diff --git a/gdb/features/aarch64-sve.c b/gdb/features/aarch64-sve.c
index 0b15881f073..24b88c32fc1 100644
--- a/gdb/features/aarch64-sve.c
+++ b/gdb/features/aarch64-sve.c
@@ -70,6 +70,12 @@ create_feature_aarch64_sve (struct target_desc *result, long regnum,
element_type = tdesc_named_type (feature, "int8");
tdesc_create_vector (feature, "svevbs", element_type, 16 * scale);
+ element_type = tdesc_named_type (feature, "fp8_e5m2");
+ tdesc_create_vector (feature, "svevbfp8e5m2", element_type, 16 * scale);
+
+ element_type = tdesc_named_type (feature, "fp8_e4m3");
+ tdesc_create_vector (feature, "svevbfp8e4m3", element_type, 16 * scale);
+
type_with_fields = tdesc_create_union (feature, "svevnq");
field_type = tdesc_named_type (feature, "svevqu");
tdesc_add_field (type_with_fields, "u", field_type);
@@ -105,6 +111,10 @@ create_feature_aarch64_sve (struct target_desc *result, long regnum,
tdesc_add_field (type_with_fields, "u", field_type);
field_type = tdesc_named_type (feature, "svevbs");
tdesc_add_field (type_with_fields, "s", field_type);
+ field_type = tdesc_named_type (feature, "svevbfp8e5m2");
+ tdesc_add_field (type_with_fields, "e5m2", field_type);
+ field_type = tdesc_named_type (feature, "svevbfp8e4m3");
+ tdesc_add_field (type_with_fields, "e4m3", field_type);
type_with_fields = tdesc_create_union (feature, "svev");
field_type = tdesc_named_type (feature, "svevnq");
--
2.45.2
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [PATCH 3/4] gdb/aarch64: Display fp8 formats in registers
2025-09-25 21:18 ` [PATCH 3/4] gdb/aarch64: Display fp8 formats in registers Ezra.Sitorus
@ 2025-10-11 13:10 ` Luis
2025-10-14 0:56 ` Ezra Sitorus
0 siblings, 1 reply; 9+ messages in thread
From: Luis @ 2025-10-11 13:10 UTC (permalink / raw)
To: Ezra.Sitorus, gdb-patches; +Cc: eliz
Hi Ezra,
Given Pedro's input about the representation of fp8's, I'm not sure this
is the right path. Enabling these types for the registers would also
make the types visible to the rest of GDB. And users can operate on them
via arithmetic operators etc.
Being integers, the ending result wouldn´t be correct.
It might be viable to explore the python extension option to print the
types accordingly. We already make vector fields (neon or sve) available
as 8, 16, 32, 64 and 128 integers. Converting from that would therefore
be easy.
Also, I'm not too keen on expanding even further these neon/sve union
types. They are very hard to parse due to the multitude of
representations. Ideally we´d put together some pseudo-registers to do
the job. That would also help with remote debugging stub target
description compatibility, as those wouldn´t need to expose these
internal details of gdb.
Thoughts?
On 25/09/2025 22:18, Ezra.Sitorus@arm.com wrote:
> From: Ezra Sitorus <ezra.sitorus@arm.com>
>
> Display fp8 formats for AArch64 vector/float registers. On a system
> without SVE, the V register and B-pseudo registers have the new
> e5m2/e4m3 formats. If it has SVE, then the Z registers, V and B pseudo
> registers get the new e5m2/e4m3 formats.
> ---
> gdb/aarch64-tdep.c | 41 ++++++++++++++++++++++++++++++++++++
> gdb/aarch64-tdep.h | 4 ++++
> gdb/features/aarch64-fpu.c | 10 +++++++++
> gdb/features/aarch64-fpu.xml | 4 ++++
> gdb/features/aarch64-sve.c | 10 +++++++++
> 5 files changed, 69 insertions(+)
>
> diff --git a/gdb/aarch64-tdep.c b/gdb/aarch64-tdep.c
> index 500ac77d75a..8e71a75efbb 100644
> --- a/gdb/aarch64-tdep.c
> +++ b/gdb/aarch64-tdep.c
> @@ -2106,6 +2106,40 @@ aarch64_frame_align (struct gdbarch *gdbarch, CORE_ADDR sp)
> return sp & ~(CORE_ADDR) 15;
> }
>
> +/* Return the type for FP8 E5M2 format. */
> +
> +static struct type *
> +aarch64_fp8_e5m2_type (struct gdbarch *gdbarch)
> +{
> + aarch64_gdbarch_tdep *tdep = gdbarch_tdep<aarch64_gdbarch_tdep> (gdbarch);
> +
> + if (!tdep->fp8_e5m2_type)
> + {
> + type_allocator alloc (gdbarch);
> + tdep->fp8_e5m2_type = init_float_type (
> + alloc, -1, "builtin_type_fp8_e5m2", floatformats_fp8_e5m2);
> + }
> +
> + return tdep->fp8_e5m2_type;
> +}
> +
> +/* Return the type for FP8 E4M3 format. */
> +
> +static struct type *
> +aarch64_fp8_e4m3_type (struct gdbarch *gdbarch)
> +{
> + aarch64_gdbarch_tdep *tdep = gdbarch_tdep<aarch64_gdbarch_tdep> (gdbarch);
> +
> + if (!tdep->fp8_e4m3_type)
> + {
> + type_allocator alloc (gdbarch);
> + tdep->fp8_e4m3_type = init_float_type (
> + alloc, -1, "builtin_type_fp8_e4m3", floatformats_fp8_e4m3);
> + }
> +
> + return tdep->fp8_e4m3_type;
> +}
> +
> /* Return the type for an AdvSISD Q register. */
>
> static struct type *
> @@ -2247,6 +2281,9 @@ aarch64_vnb_type (struct gdbarch *gdbarch)
> elem = builtin_type (gdbarch)->builtin_int8;
> append_composite_type_field (t, "s", elem);
>
> + append_composite_type_field (t, "e5m2", aarch64_fp8_e5m2_type (gdbarch));
> + append_composite_type_field (t, "e4m3", aarch64_fp8_e4m3_type (gdbarch));
> +
> tdep->vnb_type = t;
> }
>
> @@ -2516,6 +2553,10 @@ aarch64_vnv_type (struct gdbarch *gdbarch)
> init_vector_type (bt->builtin_uint8, 16));
> append_composite_type_field (sub, "s",
> init_vector_type (bt->builtin_int8, 16));
> + append_composite_type_field (sub, "e5m2",
> + init_vector_type (aarch64_fp8_e5m2_type (gdbarch), 16));
> + append_composite_type_field (sub, "e4m3",
> + init_vector_type (aarch64_fp8_e4m3_type (gdbarch), 16));
> append_composite_type_field (t, "b", sub);
>
> sub = arch_composite_type (gdbarch, "__gdb_builtin_type_vnq",
> diff --git a/gdb/aarch64-tdep.h b/gdb/aarch64-tdep.h
> index 99e7d26ce4a..d9f44f1c15c 100644
> --- a/gdb/aarch64-tdep.h
> +++ b/gdb/aarch64-tdep.h
> @@ -93,6 +93,10 @@ struct aarch64_gdbarch_tdep : gdbarch_tdep_base
> struct type *sme_tile_slice_type_h = nullptr;
> struct type *sme_tile_slice_type_b = nullptr;
>
> + /* Types for FP8 formats. */
> + struct type *fp8_e5m2_type = nullptr;
> + struct type *fp8_e4m3_type = nullptr;
> +
> /* Vector of names for SME pseudo-registers. The number of elements is
> different for each distinct svl value. */
> std::vector<std::string> sme_pseudo_names;
> diff --git a/gdb/features/aarch64-fpu.c b/gdb/features/aarch64-fpu.c
> index 27e75524cfe..13825c74640 100644
> --- a/gdb/features/aarch64-fpu.c
> +++ b/gdb/features/aarch64-fpu.c
> @@ -46,6 +46,12 @@ create_feature_aarch64_fpu (struct target_desc *result, long regnum)
> element_type = tdesc_named_type (feature, "int8");
> tdesc_create_vector (feature, "v16i", element_type, 16);
>
> + element_type = tdesc_named_type (feature, "fp8_e5m2");
> + tdesc_create_vector (feature, "v16fp8e5m2", element_type, 16);
> +
> + element_type = tdesc_named_type (feature, "fp8_e4m3");
> + tdesc_create_vector (feature, "v16fp8e4m3", element_type, 16);
> +
> element_type = tdesc_named_type (feature, "uint128");
> tdesc_create_vector (feature, "v1u", element_type, 1);
>
> @@ -85,6 +91,10 @@ create_feature_aarch64_fpu (struct target_desc *result, long regnum)
> tdesc_add_field (type_with_fields, "u", field_type);
> field_type = tdesc_named_type (feature, "v16i");
> tdesc_add_field (type_with_fields, "s", field_type);
> + field_type = tdesc_named_type (feature, "v16fp8e5m2");
> + tdesc_add_field (type_with_fields, "e5m2", field_type);
> + field_type = tdesc_named_type (feature, "v16fp8e4m3");
> + tdesc_add_field (type_with_fields, "e4m3", field_type);
>
> type_with_fields = tdesc_create_union (feature, "vnq");
> field_type = tdesc_named_type (feature, "v1u");
> diff --git a/gdb/features/aarch64-fpu.xml b/gdb/features/aarch64-fpu.xml
> index 509824f55fb..26e292ee625 100644
> --- a/gdb/features/aarch64-fpu.xml
> +++ b/gdb/features/aarch64-fpu.xml
> @@ -20,6 +20,8 @@
> <vector id="v8bf16" type="bfloat16" count="8"/>
> <vector id="v16u" type="uint8" count="16"/>
> <vector id="v16i" type="int8" count="16"/>
> + <vector id="v16fp8e5m2" type="fp8_e5m2" count="16"/>
> + <vector id="v16fp8e4m3" type="fp8_e4m3" count="16"/>
> <vector id="v1u" type="uint128" count="1"/>
> <vector id="v1i" type="int128" count="1"/>
> <union id="vnd">
> @@ -41,6 +43,8 @@
> <union id="vnb">
> <field name="u" type="v16u"/>
> <field name="s" type="v16i"/>
> + <field name="e5m2" type="v16fp8e5m2"/>
> + <field name="e4m3" type="v16fp8e4m3"/>
> </union>
> <union id="vnq">
> <field name="u" type="v1u"/>
> diff --git a/gdb/features/aarch64-sve.c b/gdb/features/aarch64-sve.c
> index 0b15881f073..24b88c32fc1 100644
> --- a/gdb/features/aarch64-sve.c
> +++ b/gdb/features/aarch64-sve.c
> @@ -70,6 +70,12 @@ create_feature_aarch64_sve (struct target_desc *result, long regnum,
> element_type = tdesc_named_type (feature, "int8");
> tdesc_create_vector (feature, "svevbs", element_type, 16 * scale);
>
> + element_type = tdesc_named_type (feature, "fp8_e5m2");
> + tdesc_create_vector (feature, "svevbfp8e5m2", element_type, 16 * scale);
> +
> + element_type = tdesc_named_type (feature, "fp8_e4m3");
> + tdesc_create_vector (feature, "svevbfp8e4m3", element_type, 16 * scale);
> +
> type_with_fields = tdesc_create_union (feature, "svevnq");
> field_type = tdesc_named_type (feature, "svevqu");
> tdesc_add_field (type_with_fields, "u", field_type);
> @@ -105,6 +111,10 @@ create_feature_aarch64_sve (struct target_desc *result, long regnum,
> tdesc_add_field (type_with_fields, "u", field_type);
> field_type = tdesc_named_type (feature, "svevbs");
> tdesc_add_field (type_with_fields, "s", field_type);
> + field_type = tdesc_named_type (feature, "svevbfp8e5m2");
> + tdesc_add_field (type_with_fields, "e5m2", field_type);
> + field_type = tdesc_named_type (feature, "svevbfp8e4m3");
> + tdesc_add_field (type_with_fields, "e4m3", field_type);
>
> type_with_fields = tdesc_create_union (feature, "svev");
> field_type = tdesc_named_type (feature, "svevnq");
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [PATCH 3/4] gdb/aarch64: Display fp8 formats in registers
2025-10-11 13:10 ` Luis
@ 2025-10-14 0:56 ` Ezra Sitorus
2025-10-17 10:20 ` Luis
0 siblings, 1 reply; 9+ messages in thread
From: Ezra Sitorus @ 2025-10-14 0:56 UTC (permalink / raw)
To: Luis; +Cc: gdb-patches, pedro
On Sat, Oct 11, 2025 at 02:10:11PM +0100, Luis wrote:
> Hi Ezra,
>
> Given Pedro's input about the representation of fp8's, I'm not sure this is
> the right path. Enabling these types for the registers would also make the
> types visible to the rest of GDB. And users can operate on them via
> arithmetic operators etc.
>
> Being integers, the ending result wouldn�t be correct.
>
> It might be viable to explore the python extension option to print the types
> accordingly. We already make vector fields (neon or sve) available as 8, 16,
> 32, 64 and 128 integers. Converting from that would therefore be easy.
>
Fair! I think a python pretty printer is a good idea. However, would a pretty
belong in the gdb project or the gcc project? The only examples in gdb are from
testcases. The gdb docs references gdb.libstdcxx.v6, but this exists in gcc. In
either scenario, I'm not too sure where the actual files would go to.
> Also, I'm not too keen on expanding even further these neon/sve union types.
> They are very hard to parse due to the multitude of representations. Ideally
> we�d put together some pseudo-registers to do the job. That would also help
> with remote debugging stub target description compatibility, as those
> wouldn�t need to expose these internal details of gdb.
Your previous comment seems to suggest adding a pretty printer for the registers
too but this one seems to suggest adding pseudo-registers instead. For pseudo-regs,
would the approach be something like putting the new float formats in aarch64-tdep.c,
and assigning the new pseudo regs' types to be the fp8 float formats?
Thanks!
Ezra
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 3/4] gdb/aarch64: Display fp8 formats in registers
2025-10-14 0:56 ` Ezra Sitorus
@ 2025-10-17 10:20 ` Luis
0 siblings, 0 replies; 9+ messages in thread
From: Luis @ 2025-10-17 10:20 UTC (permalink / raw)
To: Ezra Sitorus; +Cc: gdb-patches, pedro
On 14/10/2025 01:56, Ezra Sitorus wrote:
> On Sat, Oct 11, 2025 at 02:10:11PM +0100, Luis wrote:
>> Hi Ezra,
>>
>> Given Pedro's input about the representation of fp8's, I'm not sure this is
>> the right path. Enabling these types for the registers would also make the
>> types visible to the rest of GDB. And users can operate on them via
>> arithmetic operators etc.
>>
>> Being integers, the ending result wouldn�t be correct.
>>
>> It might be viable to explore the python extension option to print the types
>> accordingly. We already make vector fields (neon or sve) available as 8, 16,
>> 32, 64 and 128 integers. Converting from that would therefore be easy.
>>
>
> Fair! I think a python pretty printer is a good idea. However, would a pretty
> belong in the gdb project or the gcc project? The only examples in gdb are from
> testcases. The gdb docs references gdb.libstdcxx.v6, but this exists in gcc. In
> either scenario, I'm not too sure where the actual files would go to.
>
Right, these pretty printers usually go with whoever is producing/using
such types. So libraries/compilers etc.
With that said, we could also have a set of pretty-printers in gdb as
well as reference implementation.
>> Also, I'm not too keen on expanding even further these neon/sve union types.
>> They are very hard to parse due to the multitude of representations. Ideally
>> we�d put together some pseudo-registers to do the job. That would also help
>> with remote debugging stub target description compatibility, as those
>> wouldn�t need to expose these internal details of gdb.
>
> Your previous comment seems to suggest adding a pretty printer for the registers
> too but this one seems to suggest adding pseudo-registers instead. For pseudo-regs,
We should explore the python pretty-printers here. I don´t think we
should add pseudo-registers in this case. But if we ever have a new
representation, I think we should steer away from adding new union fields...
> would the approach be something like putting the new float formats in aarch64-tdep.c,
> and assigning the new pseudo regs' types to be the fp8 float formats?
... and then we´d have something like you describe above. Otherwise
trying to print one of the vector registers produces a wall of text that
is hard to parse.
>
> Thanks!
>
> Ezra
^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH 4/4] gdb/aarch64: Tests for verifying fp8 register formats
2025-09-25 21:18 [PATCH 0/4] gdb: Display fp8 format for AArch64 registers Ezra.Sitorus
` (2 preceding siblings ...)
2025-09-25 21:18 ` [PATCH 3/4] gdb/aarch64: Display fp8 formats in registers Ezra.Sitorus
@ 2025-09-25 21:18 ` Ezra.Sitorus
2025-09-29 17:55 ` [PATCH 0/4] gdb: Display fp8 format for AArch64 registers Pedro Alves
4 siblings, 0 replies; 9+ messages in thread
From: Ezra.Sitorus @ 2025-09-25 21:18 UTC (permalink / raw)
To: gdb-patches; +Cc: eliz, luis.machado.foss, Ezra Sitorus
From: Ezra Sitorus <ezra.sitorus@arm.com>
The non-SVE version tests the V + B registers. The SVE version tests the
Z, V and B registers.
---
gdb/testsuite/gdb.arch/aarch64-fp8-reg.c | 49 ++++++++++++++++++++++
gdb/testsuite/gdb.arch/aarch64-fp8-reg.exp | 42 +++++++++++++++++++
gdb/testsuite/gdb.arch/aarch64-fp8-sve.c | 49 ++++++++++++++++++++++
gdb/testsuite/gdb.arch/aarch64-fp8-sve.exp | 45 ++++++++++++++++++++
4 files changed, 185 insertions(+)
create mode 100644 gdb/testsuite/gdb.arch/aarch64-fp8-reg.c
create mode 100644 gdb/testsuite/gdb.arch/aarch64-fp8-reg.exp
create mode 100644 gdb/testsuite/gdb.arch/aarch64-fp8-sve.c
create mode 100644 gdb/testsuite/gdb.arch/aarch64-fp8-sve.exp
diff --git a/gdb/testsuite/gdb.arch/aarch64-fp8-reg.c b/gdb/testsuite/gdb.arch/aarch64-fp8-reg.c
new file mode 100644
index 00000000000..cd85138c176
--- /dev/null
+++ b/gdb/testsuite/gdb.arch/aarch64-fp8-reg.c
@@ -0,0 +1,49 @@
+/* This test program is part of GDB, the GNU debugger.
+
+ Copyright 2024-2025 Free Software Foundation, Inc.
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 3 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program. If not, see <http://www.gnu.org/licenses/>. */
+
+int
+main (void)
+{
+ char e4m3[] = { 0b00000001, 0b00000000, 0b10000000, 0b01111010,
+ 0b01111011, 0b01111100, 0b01111101, 0b01111110,
+ 0b01111111, 0b00001000, 0b01110000, 0b01111111,
+ 0b11111111, 0b01111110, 0b11111110, 0b0 };
+
+ char e5m2[] = { 0b00000001, 0b00000011, 0b00000100, 0b01110000,
+ 0b01111100, 0b01111101, 0b01111110, 0b11111111,
+ 0b11111100, 0b11111101, 0b11111110, 0b11111111,
+ 0b0, 0b10000000, 0b0, 0b0 };
+
+ long val;
+ void *addr = &e4m3[0];
+ __asm __volatile ("ldr %x0, [%1]\n\t"
+ "ldr q0, [%x0]"
+ : "=r"(val)
+ : "r"(&addr)
+ : "q0");
+ /* CHECK_E4M3 */
+
+ addr = &e5m2[0];
+ __asm __volatile ("ldr %x0, [%1]\n\t"
+ "ldr q0, [%x0]"
+ : "=r"(val)
+ : "r"(&addr)
+ : "q0");
+
+ /* CHECK_E5M2 */
+ return 1;
+}
diff --git a/gdb/testsuite/gdb.arch/aarch64-fp8-reg.exp b/gdb/testsuite/gdb.arch/aarch64-fp8-reg.exp
new file mode 100644
index 00000000000..41f4dcf38ea
--- /dev/null
+++ b/gdb/testsuite/gdb.arch/aarch64-fp8-reg.exp
@@ -0,0 +1,42 @@
+# Copyright 2025 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see <http://www.gnu.org/licenses/>.
+#
+# This test checks that GDB correctly displays FP8 formats in AArch64
+# vector registers.
+
+require is_aarch64_target
+
+standard_testfile
+if { [prepare_for_testing "failed to prepare" ${testfile} ${srcfile}] } {
+ return -1
+}
+
+if ![runto_main] {
+ return -1
+}
+
+set e4m3_breakpoint "CHECK_E4M3"
+gdb_breakpoint [gdb_get_line_number $e4m3_breakpoint]
+gdb_continue_to_breakpoint "Continue until E4M3 check"
+
+gdb_test "p \$v0.b.e4m3" "v0.b.e4m3.* = \{ ?0.00195, ?0, ?-0, ?320, ?352, ?384, ?416, ?448, ?nan\\(0x7\\), ?0.0156, ?128, ?nan\\(0x7\\), ?-nan\\(0x7\\), ?448, ?-448, ?0\}" "e4m3 register check"
+gdb_test "p \$b0.e4m3" "b0.e4m3.* = 0.00195" "e4m3 b pseudo-register check"
+
+set e5m2_breakpoint "CHECK_E5M2"
+gdb_breakpoint [gdb_get_line_number $e5m2_breakpoint]
+gdb_continue_to_breakpoint "Continue until E5M2 check"
+
+gdb_test "p \$v0.b.e5m2" "v0.b.e5m2.* = \{ ?1.5e-05, ?4.6e-05, ?6.1e-05, ?8.2e\\+03, ?inf, ?nan\\(0x1\\), ?nan\\(0x2\\), ?-nan\\(0x3\\), ?-inf, ?-nan\\(0x1\\), ?-nan\\(0x2\\), ?-nan\\(0x3\\), ?0, ?-0, ?0, ?0\}" "e5m2 register check"
+gdb_test "p \$b0.e5m2" "b0.e5m2.* = 1.5e-05" "e5m2 b pseudo-register check"
diff --git a/gdb/testsuite/gdb.arch/aarch64-fp8-sve.c b/gdb/testsuite/gdb.arch/aarch64-fp8-sve.c
new file mode 100644
index 00000000000..cd85138c176
--- /dev/null
+++ b/gdb/testsuite/gdb.arch/aarch64-fp8-sve.c
@@ -0,0 +1,49 @@
+/* This test program is part of GDB, the GNU debugger.
+
+ Copyright 2024-2025 Free Software Foundation, Inc.
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 3 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program. If not, see <http://www.gnu.org/licenses/>. */
+
+int
+main (void)
+{
+ char e4m3[] = { 0b00000001, 0b00000000, 0b10000000, 0b01111010,
+ 0b01111011, 0b01111100, 0b01111101, 0b01111110,
+ 0b01111111, 0b00001000, 0b01110000, 0b01111111,
+ 0b11111111, 0b01111110, 0b11111110, 0b0 };
+
+ char e5m2[] = { 0b00000001, 0b00000011, 0b00000100, 0b01110000,
+ 0b01111100, 0b01111101, 0b01111110, 0b11111111,
+ 0b11111100, 0b11111101, 0b11111110, 0b11111111,
+ 0b0, 0b10000000, 0b0, 0b0 };
+
+ long val;
+ void *addr = &e4m3[0];
+ __asm __volatile ("ldr %x0, [%1]\n\t"
+ "ldr q0, [%x0]"
+ : "=r"(val)
+ : "r"(&addr)
+ : "q0");
+ /* CHECK_E4M3 */
+
+ addr = &e5m2[0];
+ __asm __volatile ("ldr %x0, [%1]\n\t"
+ "ldr q0, [%x0]"
+ : "=r"(val)
+ : "r"(&addr)
+ : "q0");
+
+ /* CHECK_E5M2 */
+ return 1;
+}
diff --git a/gdb/testsuite/gdb.arch/aarch64-fp8-sve.exp b/gdb/testsuite/gdb.arch/aarch64-fp8-sve.exp
new file mode 100644
index 00000000000..ef79f0fd036
--- /dev/null
+++ b/gdb/testsuite/gdb.arch/aarch64-fp8-sve.exp
@@ -0,0 +1,45 @@
+# Copyright 2025 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see <http://www.gnu.org/licenses/>.
+#
+# This test checks that GDB correctly displays FP8 formats in AArch64
+# vector registers.
+
+require is_aarch64_target
+require allow_aarch64_sve_tests
+
+standard_testfile
+if { [prepare_for_testing "failed to prepare" ${testfile} ${srcfile}] } {
+ return -1
+}
+
+if ![runto_main] {
+ return -1
+}
+
+set e4m3_breakpoint "CHECK_E4M3"
+gdb_breakpoint [gdb_get_line_number $e4m3_breakpoint]
+gdb_continue_to_breakpoint "Continue until E4M3 check"
+
+gdb_test "p \$z0.b.e4m3" "z0.b.e4m3.* = \{ ?0.00195, ?0, ?-0, ?320, ?352, ?384, ?416, ?448, ?nan\\(0x7\\), ?0.0156, ?128, ?nan\\(0x7\\), ?-nan\\(0x7\\), ?448, ?-448, ?0.*\}" "e4m3 z register check"
+gdb_test "p \$v0.b.e4m3" "v0.b.e4m3.* = \{ ?0.00195, ?0, ?-0, ?320, ?352, ?384, ?416, ?448, ?nan\\(0x7\\), ?0.0156, ?128, ?nan\\(0x7\\), ?-nan\\(0x7\\), ?448, ?-448, ?0\}" "e4m3 v pseudo register check"
+gdb_test "p \$b0.e4m3" "b0.e4m3.* = 0.00195" "e4m3 b pseudo-register check"
+
+set e5m2_breakpoint "CHECK_E5M2"
+gdb_breakpoint [gdb_get_line_number $e5m2_breakpoint]
+gdb_continue_to_breakpoint "Continue until E5M2 check"
+
+gdb_test "p \$z0.b.e5m2" "z0.b.e5m2.* = \{ ?1.5e-05, ?4.6e-05, ?6.1e-05, ?8.2e\\+03, ?inf, ?nan\\(0x1\\), ?nan\\(0x2\\), ?-nan\\(0x3\\), ?-inf, ?-nan\\(0x1\\), ?-nan\\(0x2\\), ?-nan\\(0x3\\), ?0, ?-0, ?0.*\}" "e5m2 z register check"
+gdb_test "p \$v0.b.e5m2" "v0.b.e5m2.* = \{ ?1.5e-05, ?4.6e-05, ?6.1e-05, ?8.2e\\+03, ?inf, ?nan\\(0x1\\), ?nan\\(0x2\\), ?-nan\\(0x3\\), ?-inf, ?-nan\\(0x1\\), ?-nan\\(0x2\\), ?-nan\\(0x3\\), ?0, ?-0, ?0, ?0\}" "e5m2 v pseudo register check"
+gdb_test "p \$b0.e5m2" "b0.e5m2.* = 1.5e-05" "e5m2 b pseudo-register check"
--
2.45.2
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [PATCH 0/4] gdb: Display fp8 format for AArch64 registers
2025-09-25 21:18 [PATCH 0/4] gdb: Display fp8 format for AArch64 registers Ezra.Sitorus
` (3 preceding siblings ...)
2025-09-25 21:18 ` [PATCH 4/4] gdb/aarch64: Tests for verifying fp8 register formats Ezra.Sitorus
@ 2025-09-29 17:55 ` Pedro Alves
4 siblings, 0 replies; 9+ messages in thread
From: Pedro Alves @ 2025-09-29 17:55 UTC (permalink / raw)
To: Ezra.Sitorus, gdb-patches; +Cc: eliz, luis.machado.foss
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
^ permalink raw reply [flat|nested] 9+ messages in thread