RFC: Add optional _Float16 support

[H.J. Lu]

This change specifies how _Float16 should be passed and returned on
x86-64. Any comments?

* low-level-sys-info.tex (Fundamental Types): Add _Float16.
(Scalar Types): Add _Float16. Separate DFP from FP.
(Classification): Add _Float16.
---
low-level-sys-info.tex | 30 ++++++++++++++++++------------
1 file changed, 18 insertions(+), 12 deletions(-)

diff --git a/low-level-sys-info.tex b/low-level-sys-info.tex
index 66270b9..bedcb04 100644
--- a/low-level-sys-info.tex
+++ b/low-level-sys-info.tex
@@ -25,7 +25,8 @@ object, and the term \emph{\textindex{\sixteenbyte{}}} refers to a
\subsubsection{Fundamental Types}

Figure~\ref{basic-types} shows the correspondence between ISO C's
-scalar types and the processor's. \code{__int128}, \code{__float80},
+scalar types and the processor's. \code{__int128}, \code{_Float16},
+\code{__float80},
\code{__float128}, \code{__m64}, \code{__m128}, \code{__m256} and
\code{__m512} types are optional.

@@ -83,17 +84,19 @@ scalar types and the processor's. \code{__int128}, \code{__float80},
& \texttt{\textit{any-type} * (ILP32)} & 4 & 4 & unsigned \fourbyte \\
& \texttt{\textit{any-type} (*)() (ILP32)} & & \\
\hline
- Floating-& \texttt{float} & 4 & 4 & single (IEEE-754) \\
+ & \texttt{_Float16}$^{\dagger\dagger\dagger\dagger\dagger\dagger}$ & 2 & 2 & 16-bit (IEEE-754) \\
\cline{2-5}
- point & \texttt{double} & 8
+ & \texttt{float} & 4 & 4 & single (IEEE-754) \\
+ \cline{2-5}
+ Floating- & \texttt{double} & 8
& 8$^{\dagger\dagger\dagger\dagger}$ & double (IEEE-754) \\
\cline{2-5}
- & \texttt{__float80}$^{\dagger\dagger}$ & 16 & 16 & 80-bit extended (IEEE-754) \\
+ point & \texttt{__float80}$^{\dagger\dagger}$ & 16 & 16 & 80-bit extended (IEEE-754) \\
& \texttt{long double}$^{\dagger\dagger\dagger\dagger\dagger}$ & 16 & 16 & 80-bit extended (IEEE-754) \\
\cline{2-5}
& \texttt{__float128}$^{\dagger\dagger}$ & 16 & 16 & 128-bit extended (IEEE-754) \\
& \texttt{long double}$^{\dagger\dagger\dagger\dagger\dagger}$ & 16 & 16 & 128-bit extended (IEEE-754) \\
- \cline{2-5}
+ \hline
Decimal-& \texttt{_Decimal32} & 4 & 4 & 32bit BID (IEEE-754R) \\
\cline{2-5}
floating-& \texttt{_Decimal64} & 8 & 8 & 64bit BID (IEEE-754R) \\
@@ -109,22 +112,24 @@ scalar types and the processor's. \code{__int128}, \code{__float80},
& \texttt{__m512}$^{\dagger\dagger}$ & 64 & 64 & AVX-512 \\
\noalign{\smallskip}
\cline{1-5}
-\multicolumn{3}{l}{\small $^\dagger$ This type is called \texttt{bool}
+\multicolumn{3}{l}{\myfontsize $^\dagger$ This type is called \texttt{bool}
in C++.}\\
-\multicolumn{3}{l}{\small $^{\dagger\dagger}$ These types are optional.}\\
-\multicolumn{5}{p{13cm}}{\small $^{\dagger\dagger\dagger}$ C++ and some
+\multicolumn{3}{l}{\myfontsize $^{\dagger\dagger}$ These types are optional.}\\
+\multicolumn{5}{p{13cm}}{\myfontsize $^{\dagger\dagger\dagger}$ C++ and some
implementations of C permit enums larger than an int. The underlying
type is bumped to an unsigned int, long int or unsigned long int, in
that order.}\\
-\multicolumn{5}{p{13cm}}{\small $^{\dagger\dagger\dagger\dagger}$
+\multicolumn{5}{p{13cm}}{\myfontsize $^{\dagger\dagger\dagger\dagger}$
The \texttt{long long}, \texttt{signed long long},
\texttt{unsigned long long} and \texttt{double} types have 4-byte
alignment in the \intelabi.}\\
-\multicolumn{5}{p{13cm}}{\small $^{\dagger\dagger\dagger\dagger\dagger}$
+\multicolumn{5}{p{13cm}}{\myfontsize $^{\dagger\dagger\dagger\dagger\dagger}$
The \texttt{long double} type is 128-bit, the same as the \texttt{__float128}
type, on the Android{\texttrademark} platform. More information on the
Android{\texttrademark} platform is available from
\url{http://www.android.com/}.}\\
+\multicolumn{5}{p{13cm}}{\myfontsize $^{\dagger\dagger\dagger\dagger\dagger\dagger}$
+The \texttt{_Float16} type, from ISO/IEC TS 18661-3:2015, is optional.}\\
\end{tabular}
}
\end{figure}
@@ -411,7 +416,8 @@ The basic types are assigned their natural classes:
\item Arguments of types (signed and unsigned) \code{_Bool}, \code{char},
\code{short}, \code{int}, \code{long}, \code{long long}, and
pointers are in the INTEGER class.
-\item Arguments of types \code{float}, \code{double}, \code{_Decimal32},
+\item Arguments of types \code{_Float16}, \code{float}, \code{double},
+ \code{_Decimal32},
\code{_Decimal64} and \code{__m64} are in class SSE.
\item Arguments of types \code{__float128}, \code{_Decimal128}
and \code{__m128} are split into two halves. The least significant
@@ -440,7 +446,7 @@ with the exception that arguments of type \code{__int128} that are
stored in memory must be aligned on a 16-byte boundary.

\item Arguments of \code{complex T} where \code{T} is one of the types
- \code{float or double} are treated as if they are
+ \code{_Float16, float or double} are treated as if they are
implemented as:
\begin{verbatim}
struct complexT {
--
2.20.1

[Michael Matz]

Hi,

On Wed, 20 Feb 2019, H.J. Lu wrote:

> This change specifies how _Float16 should be passed and returned on
> x86-64. Any comments?

That seems sensible.


Ciao,
Michael.

[Joseph Myers]

On Wed, 20 Feb 2019, H.J. Lu wrote:

> This change specifies how _Float16 should be passed and returned on
> x86-64. Any comments?
>
> * low-level-sys-info.tex (Fundamental Types): Add _Float16.
> (Scalar Types): Add _Float16. Separate DFP from FP.
> (Classification): Add _Float16.

The ABI seems the obvious one for _Float16 / _Complex _Float16. Are you
planning to implement GCC support for this? libc support? (From
discussions at the last GNU Tools Cauldron my understanding is that Arm
doesn't have any plans for such libc support for _Float16.)

Separately from documenting the _Float16 ABI, it would be a good idea to
document the ABI for other _FloatN / _FloatNx types, as implemented in GCC
7 and later. (So _Float32 matches float; _Float32x and _Float64 match
double; _Float64x matches long double; _Float128 matches __float128.
With a note that this is describing semantics *after* any language-level
rules have been applied - float gets promoted to double in variable
arguments, but _Float32 remains unchanged, so in that particular context
_Float32 and float end up with a different ABI at the C level.)

--
Joseph S. Myers
jos...@codesourcery.com

[H.J. Lu]

On Wed, Feb 20, 2019 at 6:27 AM Joseph Myers <jos...@codesourcery.com> wrote:
>
> On Wed, 20 Feb 2019, H.J. Lu wrote:
>
> > This change specifies how _Float16 should be passed and returned on
> > x86-64. Any comments?
> >
> > * low-level-sys-info.tex (Fundamental Types): Add _Float16.
> > (Scalar Types): Add _Float16. Separate DFP from FP.
> > (Classification): Add _Float16.
>
> The ABI seems the obvious one for _Float16 / _Complex _Float16. Are you
> planning to implement GCC support for this? libc support? (From

We have no plan to support it in GCC.

> discussions at the last GNU Tools Cauldron my understanding is that Arm
> doesn't have any plans for such libc support for _Float16.)
>
> Separately from documenting the _Float16 ABI, it would be a good idea to
> document the ABI for other _FloatN / _FloatNx types, as implemented in GCC
> 7 and later. (So _Float32 matches float; _Float32x and _Float64 match
> double; _Float64x matches long double; _Float128 matches __float128.
> With a note that this is describing semantics *after* any language-level
> rules have been applied - float gets promoted to double in variable
> arguments, but _Float32 remains unchanged, so in that particular context
> _Float32 and float end up with a different ABI at the C level.)
>

Good idea. Care to send a patch?

BTW, I can move x86-psABI to gitlab.com so that it will be much easier to
contribute.

Thanks.


--
H.J.

[H.J. Lu]

On Wed, Feb 20, 2019 at 6:21 AM Michael Matz <ma...@suse.de> wrote:
>
> Hi,
>
> On Wed, 20 Feb 2019, H.J. Lu wrote:
>
> > This change specifies how _Float16 should be passed and returned on
> > x86-64. Any comments?
>
> That seems sensible.
>

Here is the merge request:

https://gitlab.com/x86-psABIs/x86-64-ABI/-/merge_requests/5


H.J.

[Florian Weimer]

* H. J. Lu:

Does this actually specify the _Float16 encoding?

Thanks,
Florian

[H.J. Lu]

It follows ISO/IEC TS 18661-3:2015.

--
H.J.