[v2,2/4] LoongArch: Add ftint{,rm,rp}.{w,l}.{s,d} instructions

  This allows to optimize the following builtins if -fno-math-errno:

- __builtin_lrint{,f}
- __builtin_lfloor{,f}
- __builtin_lceil{,f}

Inspired by
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/605287.html.

ANYFI is added so the compiler won't try ftint.l.s if -mfpu=32.  If we
simply used GPR here an ICE would be triggered with __builtin_lrintf
and -mfpu=32.

ftint{rm,rp} instructions may raise inexact exception, so they can't be
used if -fno-trapping-math -fno-fp-int-builtin-inexact.

Note that the .w.{s,d} variants are not tested because we don't support
ILP32 for now.

gcc/ChangeLog:

	* config/loongarch/loongarch.md (UNSPEC_FTINT): New unspec.
	(UNSPEC_FTINTRM): Likewise.
	(UNSPEC_FTINTRP): Likewise.
	(LRINT): New define_int_iterator.
	(lrint_pattern): New define_int_attr.
	(lrint_submenmonic): Likewise.
	(lrint_allow_inexact): Likewise.
	(ANYFI): New define_mode_iterator.
	(lrint<ANYF><ANYFI>): New instruction template.

gcc/testsuite/ChangeLog:

	* gcc.target/loongarch/ftint.c: New test.
	* gcc.target/loongarch/ftint-no-inexact.c: New test.
---
 gcc/config/loongarch/loongarch.md             | 34 ++++++++++++++
 .../gcc.target/loongarch/ftint-no-inexact.c   | 44 +++++++++++++++++++
 gcc/testsuite/gcc.target/loongarch/ftint.c    | 44 +++++++++++++++++++
 3 files changed, 122 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/loongarch/ftint-no-inexact.c
 create mode 100644 gcc/testsuite/gcc.target/loongarch/ftint.c
  

在 2022/11/9 下午9:53, Xi Ruoyao 写道:
> +;; Convert floating-point numbers to integers
> +(define_insn "<lrint_pattern><ANYF:mode><ANYFI:mode>2"
> +  [(set (match_operand:ANYFI 0 "register_operand" "=f")
> +	(unspec:ANYFI [(match_operand:ANYF 1 "register_operand" "f")]
> +		      LRINT))]
> +  "TARGET_HARD_FLOAT &&
> +   (<lrint_allow_inexact>
> +    || flag_fp_int_builtin_inexact
> +    || !flag_trapping_math)"
>
+    || !flag_trapping_math

I think this condition is backwards.
  

On Thu, 2022-11-10 at 14:41 +0800, Lulu Cheng wrote:
> 
> 在 2022/11/9 下午9:53, Xi Ruoyao 写道:
> > +;; Convert floating-point numbers to integers
> > +(define_insn "<lrint_pattern><ANYF:mode><ANYFI:mode>2"
> > +  [(set (match_operand:ANYFI 0 "register_operand" "=f")
> > +       (unspec:ANYFI [(match_operand:ANYF 1 "register_operand"
> > "f")]
> > +                     LRINT))]
> > +  "TARGET_HARD_FLOAT &&
> > +   (<lrint_allow_inexact>
> > +    || flag_fp_int_builtin_inexact
> > +    || !flag_trapping_math)"
> > 
> +    || !flag_trapping_math
> 
> I think this condition is backwards.

I copied the logic from aarch64.md:6702.

Joseph: can you confirm that -ftrapping-math allows floor and ceil to
raise inexact exception?  The man page currently says:

The default is -ffp-int-builtin-inexact, allowing the exception to be
raised, unless C2X or a later C standard is selected.  This option does 
                                                       ^^^^^^^^^^^
nothing unless -ftrapping-math is in effect.

To me it's not very clear that "this option" stands for -fno-fp-int-
builtin-inexact or -ffp-int-builtin-inexact.
  

On Thu, 10 Nov 2022, Xi Ruoyao via Gcc-patches wrote:

> Joseph: can you confirm that -ftrapping-math allows floor and ceil to
> raise inexact exception?  The man page currently says:
> 
> The default is -ffp-int-builtin-inexact, allowing the exception to be
> raised, unless C2X or a later C standard is selected.  This option does 
>                                                        ^^^^^^^^^^^
> nothing unless -ftrapping-math is in effect.
> 
> To me it's not very clear that "this option" stands for -fno-fp-int-
> builtin-inexact or -ffp-int-builtin-inexact.

The -ftrapping-math option (which is on by default) means that we care 
about whether operations raise exceptions: they should raise exceptions if 
and only if the relevant standard permit them to do so.

The combination of -ftrapping-math with -fno-fp-int-builtin-inexact means 
the listed built-in functions must not raise "inexact".

If -fno-trapping-math is used, then we don't care about whether exceptions 
are raised or not (for any floating-point operations, not just those 
functions).  So given -fno-trapping-math, there is no difference between 
-fno-fp-int-builtin-inexact and -ffp-int-builtin-inexact.

If -ffp-int-builtin-inexact (default before C2X), we don't care about 
whether those functions raise "inexact" (but still care about other 
exceptions and exceptions for other operations, unless 
-fno-trapping-math).
  

Lulu:

So I think the code is correct:

+   (<lrint_allow_inexact>
+    || flag_fp_int_builtin_inexact
+    || !flag_trapping_math)"

<lrint_allow_inexact> is 1 for lrint, 0 for lceil and lfloor.  As N3054
says:

   The lrint and llrint functions provide floating-to-integer conversion as prescribed by IEC 60559.
   They round according to the current rounding direction. If the rounded value is outside the range of
   the return type, the numeric result is unspecified and the "invalid" floating-point exception is raised.
   When they raise no other floating-point exception and the result differs from the argument, they
   raise the "inexact" floating-point exception.
   
If flag_fp_int_builtin_inexact is set, we allow lceil and lfloor to
raise "inexact".

If flag_trapping_math is not set (it's set by default and can only be
unset explicitly with -fno-trapping-math: it's not even implied by -
ffast-math), we don't care about whether exceptions are raised or not.

So lceil and lfloor can be used if -ffp-int-builtin-inexact, or -fno-
trapping-math.

On Fri, 2022-11-11 at 00:07 +0000, Joseph Myers wrote:
> On Thu, 10 Nov 2022, Xi Ruoyao via Gcc-patches wrote:
> 
> > Joseph: can you confirm that -ftrapping-math allows floor and ceil to
> > raise inexact exception?  The man page currently says:
> > 
> > The default is -ffp-int-builtin-inexact, allowing the exception to be
> > raised, unless C2X or a later C standard is selected.  This option does 
> >                                                        ^^^^^^^^^^^
> > nothing unless -ftrapping-math is in effect.
> > 
> > To me it's not very clear that "this option" stands for -fno-fp-int-
> > builtin-inexact or -ffp-int-builtin-inexact.
> 
> The -ftrapping-math option (which is on by default) means that we care
> about whether operations raise exceptions: they should raise exceptions if 
> and only if the relevant standard permit them to do so.
> 
> The combination of -ftrapping-math with -fno-fp-int-builtin-inexact means 
> the listed built-in functions must not raise "inexact".
> 
> If -fno-trapping-math is used, then we don't care about whether exceptions 
> are raised or not (for any floating-point operations, not just those 
> functions).  So given -fno-trapping-math, there is no difference between 
> -fno-fp-int-builtin-inexact and -ffp-int-builtin-inexact.
> 
> If -ffp-int-builtin-inexact (default before C2X), we don't care about 
> whether those functions raise "inexact" (but still care about other 
> exceptions and exceptions for other operations, unless 
> -fno-trapping-math).
  

I have no more questions.

Thanks.

在 2022/11/11 下午1:29, Xi Ruoyao 写道:
> Lulu:
>
> So I think the code is correct:
>
> +   (<lrint_allow_inexact>
> +    || flag_fp_int_builtin_inexact
> +    || !flag_trapping_math)"
>
> <lrint_allow_inexact> is 1 for lrint, 0 for lceil and lfloor.  As N3054
> says:
>
>     The lrint and llrint functions provide floating-to-integer conversion as prescribed by IEC 60559.
>     They round according to the current rounding direction. If the rounded value is outside the range of
>     the return type, the numeric result is unspecified and the "invalid" floating-point exception is raised.
>     When they raise no other floating-point exception and the result differs from the argument, they
>     raise the "inexact" floating-point exception.
>     
> If flag_fp_int_builtin_inexact is set, we allow lceil and lfloor to
> raise "inexact".
>
> If flag_trapping_math is not set (it's set by default and can only be
> unset explicitly with -fno-trapping-math: it's not even implied by -
> ffast-math), we don't care about whether exceptions are raised or not.
>
> So lceil and lfloor can be used if -ffp-int-builtin-inexact, or -fno-
> trapping-math.
>
> On Fri, 2022-11-11 at 00:07 +0000, Joseph Myers wrote:
>> On Thu, 10 Nov 2022, Xi Ruoyao via Gcc-patches wrote:
>>
>>> Joseph: can you confirm that -ftrapping-math allows floor and ceil to
>>> raise inexact exception?  The man page currently says:
>>>
>>> The default is -ffp-int-builtin-inexact, allowing the exception to be
>>> raised, unless C2X or a later C standard is selected.  This option does
>>>                                                         ^^^^^^^^^^^
>>> nothing unless -ftrapping-math is in effect.
>>>
>>> To me it's not very clear that "this option" stands for -fno-fp-int-
>>> builtin-inexact or -ffp-int-builtin-inexact.
>> The -ftrapping-math option (which is on by default) means that we care
>> about whether operations raise exceptions: they should raise exceptions if
>> and only if the relevant standard permit them to do so.
>>
>> The combination of -ftrapping-math with -fno-fp-int-builtin-inexact means
>> the listed built-in functions must not raise "inexact".
>>
>> If -fno-trapping-math is used, then we don't care about whether exceptions
>> are raised or not (for any floating-point operations, not just those
>> functions).  So given -fno-trapping-math, there is no difference between
>> -fno-fp-int-builtin-inexact and -ffp-int-builtin-inexact.
>>
>> If -ffp-int-builtin-inexact (default before C2X), we don't care about
>> whether those functions raise "inexact" (but still care about other
>> exceptions and exceptions for other operations, unless
>> -fno-trapping-math).