[Dwarf-Discuss] [EXTERNAL] - RE: Multiple floating point types with the same size but different encodings

[Jakub Jelinek]

On Tue, Jan 25, 2022 at 01:55:40PM +0000, paul.robinson at sony.com wrote:
> > If s_float and f_float or t_float and g_float coexist on the same platform
> > in the same ABI, I'm afraid DW_AT_precision to distinguish between them,
> 
> Did you mean, DW_AT_precision isn't enough to distinguish between them?

Yes.  My understanding is that e.g. IEEE single and VAX f_float both use
the same number of bits for exponent and mantissa, but the difference is that
f_float uses a different exponent bias and doesn't support NaNs/Infinities.
So when describing it through the C/C++ float.h macros,
*_MANT_DIG is the same, but they differ in *_MIN_EXP and *_MAX_EXP.

> > IEEE single has 24-bit significand precision (1 bit implied) and
> > it seems s_float does too, and similarly IEEE double has 53-bit precision
> > (1 bit implied) and it seems g_gloat does too (d_float has 56-bit
> > precision).
> > So we'd need also exponent bias (or minimum or maximum exponent)
> > to differentiate between them.
> 
> It sounds like ATE codes would be better all around.  We could have a
> pile of attributes that parameterize all the things, but that seems
> overly general.

For ATE codes, the problem is with standardization if we wanted
to standardize it in some way for DWARF6.
The current DW_ATE_{,complex_}float is way too unspecific and historically
can be about various formats.
So, we'd need something like DW_ATE_{,complex_}ieee754_float
(or ieee754_binary_float?)
which would depending on DW_AT_byte_size be binary{16,32,64,128,256}
format, and then add DW_ATE_* values for the floating point formats
known to us, which would be
vax_f_float, vax_g_float, vax_d_float (what about vax_h_float?)
bfloat16
Intel extended precision
IBM extended (double double)
what else?
Anyway, it might be possible as can be seen in the DW_ATE_HP_*
extensions to reuse the same DW_ATE_* code for multiple different
formats as long as they are guaranteed to have different DW_AT_byte_size.

For DW_AT_precision/DW_AT_min_exponent/DW_AT_max_exponent we would
just define them the same way as C/C++ does define corresponding
macros, e.g. https://en.cppreference.com/w/c/types/limits
(though of course, we can only reasonably use properties that are
expressible as small integral values or booleans, can't have
attributes matching to say FLT_MAX etc., which need some floating point
values).  All could be optional and the producers would need to use them
only if without those attributes it would be ambiguous what it is.

	Jakub