[Bug c/106117] New: Use of option -fexcess-precision for operation-by-operation emulation for _Float16 arithmetics.

[Bug c/106117] New: Use of option -fexcess-precision for operation-by-operation emulation for _Float16 arithmetics.

[Zahira.Ammarguellat at intel dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106117

            Bug ID: 106117
           Summary: Use of option -fexcess-precision for
                    operation-by-operation emulation for _Float16
                    arithmetics.
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: Zahira.Ammarguellat at intel dot com
  Target Milestone: ---

We are adding in Clang the support of '_Float16' on X86 targets with SSE2
enabled. 
When the target supports AVX512-FP16, Clang performs '_Float16' arithmetic
using native support. Otherwise, '_Float16' arithmetic is performed by
promoting to 'float', then performing the operation, and finally truncating to
'_Float16'. 

This operation-by-operation emulation is the default in Clang, and is in line
with the C standard's rules for excess precision arithmetic. We would like to
adopt the option '-fexcess-precision' to request this operation-by-operation
emulation by setting '-fexcess-precision=none'. 
First are there any objections in using this option to request
operation-by-operation emulation for '_Float16' arithmetic? 
Second is 'none' the right value to use?
Thanks.

[Bug c/106117] Use of option -fexcess-precision for operation-by-operation emulation for _Float16 arithmetics.

[rjmccall at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106117

John McCall <rjmccall at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rjmccall at gmail dot com

--- Comment #1 from John McCall <rjmccall at gmail dot com> ---
To clarify one point: Clang plans to use excess precision arithmetic as the
default for _Float16 when AVX512-FP16 isn't available, following the C
standard's rules, i.e. `-fexcess-precision=standard`.  We'd like to offer users
a way to disable this and force operation-by-operation translation, but as far
as we can tell, there isn't a way to request this in GCC today.  It feels like
`-fexcess-precision=none` (or some similar spelling) would be the most
appropriate way to do this, since of course this conflicts with other values of
`-fexcess-precision`.

Since GCC originated `-fexcess-precision`, we're trying to being neighborly and
ask whether you have a problem with this extension.

[Bug c/106117] Use of option -fexcess-precision for operation-by-operation emulation for _Float16 arithmetics.

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106117

--- Comment #2 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
"none" was something I mentioned as a possible future argument when 
originally posting -fexcess-precision 
<https://gcc.gnu.org/legacy-ml/gcc-patches/2008-11/msg00105.html>.  I 
still think it's the appropriate name for that case.

(Doing +-*/ operations on float and then immediately converting back to 
_Float16 has exactly the same semantics as direct _Float16 arithmetic; 
float has sufficient precision that no double rounding issues arise; that 
doesn't apply to fma, however.  The effect of excess precision is that 
e.g. in "a + b + c", the value of a + b with the range and precision of 
float is what gets added to c; there's no intermediate truncation of a + b 
to _Float16.  But (_Float16)(a + b) + c would have such a truncation, 
because casts and conversion as if by assignment remove excess range and 
precision.)

[Bug c/106117] Use of option -fexcess-precision for operation-by-operation emulation for _Float16 arithmetics.

[crazylht at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106117

--- Comment #3 from Hongtao.liu <crazylht at gmail dot com> ---
we're using -fexcess-precision=16 to force operation-by-operation translation
when  AVX512-FP16 is not available.

https://gcc.gnu.org/pipermail/gcc-patches/2021-August/576493.html

[Bug c/106117] Use of option -fexcess-precision for operation-by-operation emulation for _Float16 arithmetics.

[rjmccall at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106117

--- Comment #4 from John McCall <rjmccall at gmail dot com> ---
Ah, thank you, we weren't aware of -fexcess-precision=16.  If that's the
precedent, we can certainly follow it.

The idea around "16" was to make it clear that this just affects _Float16?  If
the option were named -fexcess-precision=none, then I suppose someone who had
started passing it years ago to prevent float/double promotion on i386 would
now unintentionally be affected by it for _Float16.  Put another way, there's
an implicit assumption in the re-use of a single option that targets will have
a linear history of support for more floating point types, such that there's
only one kind of emulation in use at once.

[Bug c/106117] Use of option -fexcess-precision for operation-by-operation emulation for _Float16 arithmetics.

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106117

--- Comment #5 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
The idea with "16" is to say that's the exact FLT_EVAL_METHOD value 
(defined in C23 Annex H) whose semantics should be followed.  It would 
affect float/double promotion on i386 as well (the back end gives an error 
that the combination of that option with -mfpmath=387 is unsupported).

[Bug c/106117] Use of option -fexcess-precision for operation-by-operation emulation for _Float16 arithmetics.

[rjmccall at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106117

--- Comment #6 from John McCall <rjmccall at gmail dot com> ---
Ah, I can see how the FLT_EVAL_METHOD schema gives us a unifying scheme, thank
you.  Just to be clear, though, the actual value of FLT_EVAL_METHOD in that
mode should be 0, correct?

[Bug c/106117] Use of option -fexcess-precision for operation-by-operation emulation for _Float16 arithmetics.

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106117

--- Comment #7 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
FLT_EVAL_METHOD of 0 gives _Float16 excess precision ("evaluate all 
operations and constants, whose semantic type comprises a set of values 
that is a strict subset of the values of float, to the range and precision 
of float; evaluate all other operations and constants to the range and 
precision of the semantic type").  See the -fpermitted-flt-eval-methods= 
option that's used to control whether FLT_EVAL_METHOD may be defined to a 
value such as 16 that's not part of C11.

[Bug c/106117] Use of option -fexcess-precision for operation-by-operation emulation for _Float16 arithmetics.

[rjmccall at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106117

--- Comment #8 from John McCall <rjmccall at gmail dot com> ---
Oh, that's what I get for having two different draft standards open at once. 
Thanks.