builtin fenv functions

builtin fenv functions

[Marc Glisse]

[-- 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)

Re: builtin fenv functions

[Richard Biener]

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

Re: builtin fenv functions

[Marc Glisse]

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

Re: builtin fenv functions

[Richard Biener]

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

Re: builtin fenv functions

[Marc Glisse]

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

Re: builtin fenv functions

[Richard Biener]

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