public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* builtin fenv functions
@ 2017-05-26 10:27 Marc Glisse
  2017-05-26 10:39 ` Richard Biener
  0 siblings, 1 reply; 6+ messages in thread
From: Marc Glisse @ 2017-05-26 10:27 UTC (permalink / raw)
  To: gcc-patches

[-- Attachment #1: Type: TEXT/PLAIN, Size: 882 bytes --]

Hello,

coming back to https://gcc.gnu.org/ml/gcc-patches/2014-02/msg01378.html , 
Richard wanted a complete set of fenv functions instead of just the 2 I 
was interested in. However, most functions in fenv.h handle a struch 
fenv_t or fexcept_t, which makes them inconvenient to handle as builtins. 
Similarly, I don't see div as a builtin in that file, only FILE* has 
special code, but that doesn't seem worth the trouble here. So I am only 
declaring the 5 "simple" functions, with minimal properties: leaf, 
nothrow, and for fegetround pure (glibc already declares it that way). We 
can then discuss the safety of future optimizations on a case by case 
basis.

2017-05-29  Marc Glisse  <marc.glisse@inria.fr>

 	* builtins.def (BUILT_IN_FECLEAREXCEPT, BUILT_IN_FEGETROUND,
 	BUILT_IN_FERAISEEXCEPT, BUILT_IN_FESETROUND,
 	BUILT_IN_FETESTEXCEPT): New builtins.

-- 
Marc Glisse

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: TEXT/x-diff; name=fenv.patch, Size: 2772 bytes --]

Index: gcc/builtins.def
===================================================================
--- gcc/builtins.def	(revision 248468)
+++ gcc/builtins.def	(working copy)
@@ -357,20 +357,25 @@ DEF_C99_C90RES_BUILTIN (BUILT_IN_FABSF,
 DEF_C99_C90RES_BUILTIN (BUILT_IN_FABSL, "fabsl", BT_FN_LONGDOUBLE_LONGDOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
 #define FABS_TYPE(F) BT_FN_##F##_##F
 DEF_GCC_FLOATN_NX_BUILTINS (BUILT_IN_FABS, "fabs", FABS_TYPE, ATTR_CONST_NOTHROW_LEAF_LIST)
 #undef FABS_TYPE
 DEF_GCC_BUILTIN        (BUILT_IN_FABSD32, "fabsd32", BT_FN_DFLOAT32_DFLOAT32, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_GCC_BUILTIN        (BUILT_IN_FABSD64, "fabsd64", BT_FN_DFLOAT64_DFLOAT64, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_GCC_BUILTIN        (BUILT_IN_FABSD128, "fabsd128", BT_FN_DFLOAT128_DFLOAT128, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_C99_BUILTIN        (BUILT_IN_FDIM, "fdim", BT_FN_DOUBLE_DOUBLE_DOUBLE, ATTR_MATHFN_FPROUNDING_ERRNO)
 DEF_C99_BUILTIN        (BUILT_IN_FDIMF, "fdimf", BT_FN_FLOAT_FLOAT_FLOAT, ATTR_MATHFN_FPROUNDING_ERRNO)
 DEF_C99_BUILTIN        (BUILT_IN_FDIML, "fdiml", BT_FN_LONGDOUBLE_LONGDOUBLE_LONGDOUBLE, ATTR_MATHFN_FPROUNDING_ERRNO)
+DEF_C99_BUILTIN        (BUILT_IN_FECLEAREXCEPT, "feclearexcept", BT_FN_INT_INT, ATTR_NOTHROW_LEAF_LIST)
+DEF_C99_BUILTIN        (BUILT_IN_FEGETROUND, "fegetround", BT_FN_INT, ATTR_PURE_NOTHROW_LEAF_LIST)
+DEF_C99_BUILTIN        (BUILT_IN_FERAISEEXCEPT, "feraiseexcept", BT_FN_INT_INT, ATTR_NOTHROW_LEAF_LIST)
+DEF_C99_BUILTIN        (BUILT_IN_FESETROUND, "fesetround", BT_FN_INT_INT, ATTR_NOTHROW_LEAF_LIST)
+DEF_C99_BUILTIN        (BUILT_IN_FETESTEXCEPT, "fetestexcept", BT_FN_INT_INT, ATTR_NOTHROW_LEAF_LIST)
 DEF_LIB_BUILTIN        (BUILT_IN_FLOOR, "floor", BT_FN_DOUBLE_DOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_C99_C90RES_BUILTIN (BUILT_IN_FLOORF, "floorf", BT_FN_FLOAT_FLOAT, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_C99_C90RES_BUILTIN (BUILT_IN_FLOORL, "floorl", BT_FN_LONGDOUBLE_LONGDOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_C99_BUILTIN        (BUILT_IN_FMA, "fma", BT_FN_DOUBLE_DOUBLE_DOUBLE_DOUBLE, ATTR_MATHFN_FPROUNDING)
 DEF_C99_BUILTIN        (BUILT_IN_FMAF, "fmaf", BT_FN_FLOAT_FLOAT_FLOAT_FLOAT, ATTR_MATHFN_FPROUNDING)
 DEF_C99_BUILTIN        (BUILT_IN_FMAL, "fmal", BT_FN_LONGDOUBLE_LONGDOUBLE_LONGDOUBLE_LONGDOUBLE, ATTR_MATHFN_FPROUNDING)
 DEF_C99_BUILTIN        (BUILT_IN_FMAX, "fmax", BT_FN_DOUBLE_DOUBLE_DOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_C99_BUILTIN        (BUILT_IN_FMAXF, "fmaxf", BT_FN_FLOAT_FLOAT_FLOAT, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_C99_BUILTIN        (BUILT_IN_FMAXL, "fmaxl", BT_FN_LONGDOUBLE_LONGDOUBLE_LONGDOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_C99_BUILTIN        (BUILT_IN_FMIN, "fmin", BT_FN_DOUBLE_DOUBLE_DOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: builtin fenv functions
  2017-05-26 10:27 builtin fenv functions Marc Glisse
@ 2017-05-26 10:39 ` Richard Biener
  2017-05-26 10:49   ` Marc Glisse
  0 siblings, 1 reply; 6+ messages in thread
From: Richard Biener @ 2017-05-26 10:39 UTC (permalink / raw)
  To: Marc Glisse; +Cc: GCC Patches

On Fri, May 26, 2017 at 11:52 AM, Marc Glisse <marc.glisse@inria.fr> wrote:
> Hello,
>
> coming back to https://gcc.gnu.org/ml/gcc-patches/2014-02/msg01378.html ,
> Richard wanted a complete set of fenv functions instead of just the 2 I was
> interested in. However, most functions in fenv.h handle a struch fenv_t or
> fexcept_t, which makes them inconvenient to handle as builtins.

We do have stdio functions having FILE * arguments.  There's 'fileptr_type_node'
(pointer to incomplete struct) to handle that.  I suppose rth was looking for
sth similar for fenv_t * and fexcept_t *.  I guess it's hard to implement a
dependency scheme other than "memory" without seeing the full set of
functions.

> Similarly, I
> don't see div as a builtin in that file, only FILE* has special code, but
> that doesn't seem worth the trouble here. So I am only declaring the 5
> "simple" functions, with minimal properties: leaf, nothrow, and for
> fegetround pure (glibc already declares it that way). We can then discuss
> the safety of future optimizations on a case by case basis.

+DEF_C99_BUILTIN        (BUILT_IN_FERAISEEXCEPT, "feraiseexcept",
BT_FN_INT_INT, ATTR_NOTHROW_LEAF_LIST)

I think feraiseexcept shouldn't be nothrow?  But it may be pure?
Likewise fetestexcept may be pure?

Thanks,
Richard.

> 2017-05-29  Marc Glisse  <marc.glisse@inria.fr>
>
>         * builtins.def (BUILT_IN_FECLEAREXCEPT, BUILT_IN_FEGETROUND,
>         BUILT_IN_FERAISEEXCEPT, BUILT_IN_FESETROUND,
>         BUILT_IN_FETESTEXCEPT): New builtins.
>
> --
> Marc Glisse

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: builtin fenv functions
  2017-05-26 10:39 ` Richard Biener
@ 2017-05-26 10:49   ` Marc Glisse
  2017-05-26 10:58     ` Richard Biener
  0 siblings, 1 reply; 6+ messages in thread
From: Marc Glisse @ 2017-05-26 10:49 UTC (permalink / raw)
  To: Richard Biener; +Cc: GCC Patches

On Fri, 26 May 2017, Richard Biener wrote:

> On Fri, May 26, 2017 at 11:52 AM, Marc Glisse <marc.glisse@inria.fr> wrote:
>> Hello,
>>
>> coming back to https://gcc.gnu.org/ml/gcc-patches/2014-02/msg01378.html ,
>> Richard wanted a complete set of fenv functions instead of just the 2 I was
>> interested in. However, most functions in fenv.h handle a struch fenv_t or
>> fexcept_t, which makes them inconvenient to handle as builtins.
>
> We do have stdio functions having FILE * arguments.  There's 'fileptr_type_node'
> (pointer to incomplete struct) to handle that.  I suppose rth was looking for
> sth similar for fenv_t * and fexcept_t *.  I guess it's hard to implement a
> dependency scheme other than "memory" without seeing the full set of
> functions.

I'll see how hard it is to imitate FILE*...

>> Similarly, I
>> don't see div as a builtin in that file, only FILE* has special code, but
>> that doesn't seem worth the trouble here. So I am only declaring the 5
>> "simple" functions, with minimal properties: leaf, nothrow, and for
>> fegetround pure (glibc already declares it that way). We can then discuss
>> the safety of future optimizations on a case by case basis.
>
> +DEF_C99_BUILTIN        (BUILT_IN_FERAISEEXCEPT, "feraiseexcept",
> BT_FN_INT_INT, ATTR_NOTHROW_LEAF_LIST)
>
> I think feraiseexcept shouldn't be nothrow?

glibc marks it as nothrow. I can remove the nothrow flag for now, for 
safety. It may trap, but it does not throw a C++ exception AFAIU.

> But it may be pure?

It writes to the exception register (aka memory for now), so I would 
hardly call it pure.

> Likewise fetestexcept may be pure?

Too unsafe for now, since any FP operation can write to the memory that 
fetestexcept reads.

-- 
Marc Glisse

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: builtin fenv functions
  2017-05-26 10:49   ` Marc Glisse
@ 2017-05-26 10:58     ` Richard Biener
  2017-05-28 22:26       ` Marc Glisse
  0 siblings, 1 reply; 6+ messages in thread
From: Richard Biener @ 2017-05-26 10:58 UTC (permalink / raw)
  To: Marc Glisse; +Cc: GCC Patches

On Fri, May 26, 2017 at 12:39 PM, Marc Glisse <marc.glisse@inria.fr> wrote:
> On Fri, 26 May 2017, Richard Biener wrote:
>
>> On Fri, May 26, 2017 at 11:52 AM, Marc Glisse <marc.glisse@inria.fr>
>> wrote:
>>>
>>> Hello,
>>>
>>> coming back to https://gcc.gnu.org/ml/gcc-patches/2014-02/msg01378.html ,
>>> Richard wanted a complete set of fenv functions instead of just the 2 I
>>> was
>>> interested in. However, most functions in fenv.h handle a struch fenv_t
>>> or
>>> fexcept_t, which makes them inconvenient to handle as builtins.
>>
>>
>> We do have stdio functions having FILE * arguments.  There's
>> 'fileptr_type_node'
>> (pointer to incomplete struct) to handle that.  I suppose rth was looking
>> for
>> sth similar for fenv_t * and fexcept_t *.  I guess it's hard to implement
>> a
>> dependency scheme other than "memory" without seeing the full set of
>> functions.
>
>
> I'll see how hard it is to imitate FILE*...
>
>>> Similarly, I
>>> don't see div as a builtin in that file, only FILE* has special code, but
>>> that doesn't seem worth the trouble here. So I am only declaring the 5
>>> "simple" functions, with minimal properties: leaf, nothrow, and for
>>> fegetround pure (glibc already declares it that way). We can then discuss
>>> the safety of future optimizations on a case by case basis.
>>
>>
>> +DEF_C99_BUILTIN        (BUILT_IN_FERAISEEXCEPT, "feraiseexcept",
>> BT_FN_INT_INT, ATTR_NOTHROW_LEAF_LIST)
>>
>> I think feraiseexcept shouldn't be nothrow?
>
>
> glibc marks it as nothrow. I can remove the nothrow flag for now, for
> safety. It may trap, but it does not throw a C++ exception AFAIU.

Also with -fnon-call-exceptions?

>> But it may be pure.
>
>
> It writes to the exception register (aka memory for now), so I would hardly
> call it pure.

But it doesn't have to be ordered with control word writes/reads, no?

>> Likewise fetestexcept may be pure?
>
>
> Too unsafe for now, since any FP operation can write to the memory that
> fetestexcept reads.

Ah...  but then FP operations are not ordered with the builtins anyway,
only FP loads/stores would be.

After all having builtins is only the first easiest step of properly modeling
dependences between FP ops and the FP control/exception registers.

Richard.

>
> --
> Marc Glisse

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: builtin fenv functions
  2017-05-26 10:58     ` Richard Biener
@ 2017-05-28 22:26       ` Marc Glisse
  2017-05-29  8:46         ` Richard Biener
  0 siblings, 1 reply; 6+ messages in thread
From: Marc Glisse @ 2017-05-28 22:26 UTC (permalink / raw)
  To: Richard Biener; +Cc: GCC Patches

On Fri, 26 May 2017, Richard Biener wrote:

>>>> Similarly, I
>>>> don't see div as a builtin in that file, only FILE* has special code, but
>>>> that doesn't seem worth the trouble here. So I am only declaring the 5
>>>> "simple" functions, with minimal properties: leaf, nothrow, and for
>>>> fegetround pure (glibc already declares it that way). We can then discuss
>>>> the safety of future optimizations on a case by case basis.
>>>
>>>
>>> +DEF_C99_BUILTIN        (BUILT_IN_FERAISEEXCEPT, "feraiseexcept",
>>> BT_FN_INT_INT, ATTR_NOTHROW_LEAF_LIST)
>>>
>>> I think feraiseexcept shouldn't be nothrow?
>>
>>
>> glibc marks it as nothrow. I can remove the nothrow flag for now, for
>> safety. It may trap, but it does not throw a C++ exception AFAIU.
>
> Also with -fnon-call-exceptions?

Hmm, maybe on windows where trap handlers turn into system exceptions 
which are handled like C++ exceptions... I am happy to remove nothrow.

>>> But it may be pure.
>>
>> It writes to the exception register (aka memory for now), so I would hardly
>> call it pure.
>
> But it doesn't have to be ordered with control word writes/reads, no?

Not sure what you mean here. feraiseexcept(FE_DIVBYZERO) is equivalent to 
1./0., it writes to the exception status flag. Its order with 
respect to fetestexcept must be preserved.

>>> Likewise fetestexcept may be pure?
>>
>>
>> Too unsafe for now, since any FP operation can write to the memory that
>> fetestexcept reads.
>
> Ah...  but then FP operations are not ordered with the builtins anyway,
> only FP loads/stores would be.

Since gcc doesn't handle fenv properly, people have been using a number of 
workarounds, in particular with pass-through asm, sometimes volatile, 
occasionally with the "memory" clobber.

Some of those versions would still work with pure, but the attribute 
increases the likelyhood of breaking some of those uses, and I don't know 
if it would ever help in practice, so I would rather not add it for now. 
fegetround is very different since it can safely swap position with an 
adjacent float operation.

> After all having builtins is only the first easiest step of properly modeling
> dependences between FP ops and the FP control/exception registers.

Yes, I didn't expect adding those 5 builtins (modulo the nothrow flag) to 
be controversial...

-- 
Marc Glisse

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: builtin fenv functions
  2017-05-28 22:26       ` Marc Glisse
@ 2017-05-29  8:46         ` Richard Biener
  0 siblings, 0 replies; 6+ messages in thread
From: Richard Biener @ 2017-05-29  8:46 UTC (permalink / raw)
  To: Marc Glisse; +Cc: GCC Patches

On Mon, May 29, 2017 at 12:09 AM, Marc Glisse <marc.glisse@inria.fr> wrote:
> On Fri, 26 May 2017, Richard Biener wrote:
>
>>>>> Similarly, I
>>>>> don't see div as a builtin in that file, only FILE* has special code,
>>>>> but
>>>>> that doesn't seem worth the trouble here. So I am only declaring the 5
>>>>> "simple" functions, with minimal properties: leaf, nothrow, and for
>>>>> fegetround pure (glibc already declares it that way). We can then
>>>>> discuss
>>>>> the safety of future optimizations on a case by case basis.
>>>>
>>>>
>>>>
>>>> +DEF_C99_BUILTIN        (BUILT_IN_FERAISEEXCEPT, "feraiseexcept",
>>>> BT_FN_INT_INT, ATTR_NOTHROW_LEAF_LIST)
>>>>
>>>> I think feraiseexcept shouldn't be nothrow?
>>>
>>>
>>>
>>> glibc marks it as nothrow. I can remove the nothrow flag for now, for
>>> safety. It may trap, but it does not throw a C++ exception AFAIU.
>>
>>
>> Also with -fnon-call-exceptions?
>
>
> Hmm, maybe on windows where trap handlers turn into system exceptions which
> are handled like C++ exceptions... I am happy to remove nothrow.

Ok.  I suppose as glibc has it nothrow differing is somewhat pointless
as as soon
as someone includes the fenv.h header it'll get overridden.

>>>> But it may be pure.
>>>
>>>
>>> It writes to the exception register (aka memory for now), so I would
>>> hardly
>>> call it pure.
>>
>>
>> But it doesn't have to be ordered with control word writes/reads, no?
>
>
> Not sure what you mean here. feraiseexcept(FE_DIVBYZERO) is equivalent to
> 1./0., it writes to the exception status flag. Its order with respect to
> fetestexcept must be preserved.

I see.

>>>> Likewise fetestexcept may be pure?
>>>
>>>
>>>
>>> Too unsafe for now, since any FP operation can write to the memory that
>>> fetestexcept reads.
>>
>>
>> Ah...  but then FP operations are not ordered with the builtins anyway,
>> only FP loads/stores would be.
>
>
> Since gcc doesn't handle fenv properly, people have been using a number of
> workarounds, in particular with pass-through asm, sometimes volatile,
> occasionally with the "memory" clobber.
>
> Some of those versions would still work with pure, but the attribute
> increases the likelyhood of breaking some of those uses, and I don't know if
> it would ever help in practice, so I would rather not add it for now.
> fegetround is very different since it can safely swap position with an
> adjacent float operation.
>
>> After all having builtins is only the first easiest step of properly
>> modeling
>> dependences between FP ops and the FP control/exception registers.
>
>
> Yes, I didn't expect adding those 5 builtins (modulo the nothrow flag) to be
> controversial...

Surely not.  I'm fine with erring on the conservative side for now.

Thanks,
Richard.

> --
> Marc Glisse

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2017-05-29  8:39 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-05-26 10:27 builtin fenv functions Marc Glisse
2017-05-26 10:39 ` Richard Biener
2017-05-26 10:49   ` Marc Glisse
2017-05-26 10:58     ` Richard Biener
2017-05-28 22:26       ` Marc Glisse
2017-05-29  8:46         ` Richard Biener

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).