[GSoC-19] Implementing narrowing functions like fadd

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

[GSoC-19] Implementing narrowing functions like fadd

Tejas Joshi
Hello.
Functions like fadd, faddl take two arguments, do the addition and
return the answer in narrower precision than the argument type. The
thing that might be helpful is using the do_add function directly, if
appropriate?
The thing to consider about narrowed down return type is how it can be
achieved. The functions that operate on real numbers like real_round
and so on, do not consider the return type and do calculations on the
entire real number representation. So just defining these functions
and their return type in builtins.def and other appropriate places
would do the trick?
like:
BT_FN_FLOAT_DOUBLE_DOUBLE as return and argument type for FADD

Or it has to be narrowed down by zeroing down the trailing
out-of-precision bits?
Also, if the addition or any one of the argument exceeds the return
size, the integer part of the addition would not fit in the narrowed
type. Like, 2^32 would easily fit in double but will lose its least
significant bit in float and become 2^31. How these types are supposed
to be handled?

Thanks,
-Tejas
Reply | Threaded
Open this post in threaded view
|

Re: [GSoC-19] Implementing narrowing functions like fadd

Tejas Joshi
Hello.
I am trying to add fadd function variants and as fadd takes two
arguments, the function should be called from fold_const_call_sss ().
The function is closely modeled on function calls and cases according
to real_nextafter (), also used gdb to look at backtrace. Although I
have made changes according to real_nextafter, the function real_fadd
is not called by the test program but real_nextafter does get called.
I cant find any other places to add calls for fadd. What is missing?
The patch is attached herewith.

int
main ()
{
  float x;
  x = __builtin_fadd (3.5,1.4);
}

Also, fadd function should not have faddf variant, but is introduced
only for the sake.

Thanks,
-Tejas

On Wed, 3 Jul 2019 at 18:29, Tejas Joshi <[hidden email]> wrote:

>
> Hello.
> Functions like fadd, faddl take two arguments, do the addition and
> return the answer in narrower precision than the argument type. The
> thing that might be helpful is using the do_add function directly, if
> appropriate?
> The thing to consider about narrowed down return type is how it can be
> achieved. The functions that operate on real numbers like real_round
> and so on, do not consider the return type and do calculations on the
> entire real number representation. So just defining these functions
> and their return type in builtins.def and other appropriate places
> would do the trick?
> like:
> BT_FN_FLOAT_DOUBLE_DOUBLE as return and argument type for FADD
>
> Or it has to be narrowed down by zeroing down the trailing
> out-of-precision bits?
> Also, if the addition or any one of the argument exceeds the return
> size, the integer part of the addition would not fit in the narrowed
> type. Like, 2^32 would easily fit in double but will lose its least
> significant bit in float and become 2^31. How these types are supposed
> to be handled?
>
> Thanks,
> -Tejas

fadd.diff (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [GSoC-19] Implementing narrowing functions like fadd

Tejas Joshi
Hello.
I have added fadd variants in builtins.def. For fadd and faddl
variants, I had to introduce builtin function types in
builtin-types.def :

+DEF_FUNCTION_TYPE_2 (BT_FN_FLOAT_DOUBLE_DOUBLE,
+                    BT_FLOAT, BT_DOUBLE, BT_DOUBLE)
+DEF_FUNCTION_TYPE_2 (BT_FN_FLOAT_LONGDOUBLE_LONGDOUBLE,
+                    BT_FLOAT, BT_LONGDOUBLE, BT_LONGDOUBLE)

and used them to define function in builtins.def. At this point, only
faddf variant is getting called by test program :

int main ()
{
    double z = __builtin_faddf (3.5, 1.4);
}
faddf variant is using BT_FN_FLOAT_FLOAT_FLOAT which is already
defined in builtin-types.def means I need not to introduce it. Why
fadd and faddl are not getting called in this patch? I don't find any
other place where these function types needs to be added.

Thanks,
-Tejas

On Sat, 6 Jul 2019 at 18:29, Tejas Joshi <[hidden email]> wrote:

>
> Hello.
> I am trying to add fadd function variants and as fadd takes two
> arguments, the function should be called from fold_const_call_sss ().
> The function is closely modeled on function calls and cases according
> to real_nextafter (), also used gdb to look at backtrace. Although I
> have made changes according to real_nextafter, the function real_fadd
> is not called by the test program but real_nextafter does get called.
> I cant find any other places to add calls for fadd. What is missing?
> The patch is attached herewith.
>
> int
> main ()
> {
>   float x;
>   x = __builtin_fadd (3.5,1.4);
> }
>
> Also, fadd function should not have faddf variant, but is introduced
> only for the sake.
>
> Thanks,
> -Tejas
>
> On Wed, 3 Jul 2019 at 18:29, Tejas Joshi <[hidden email]> wrote:
> >
> > Hello.
> > Functions like fadd, faddl take two arguments, do the addition and
> > return the answer in narrower precision than the argument type. The
> > thing that might be helpful is using the do_add function directly, if
> > appropriate?
> > The thing to consider about narrowed down return type is how it can be
> > achieved. The functions that operate on real numbers like real_round
> > and so on, do not consider the return type and do calculations on the
> > entire real number representation. So just defining these functions
> > and their return type in builtins.def and other appropriate places
> > would do the trick?
> > like:
> > BT_FN_FLOAT_DOUBLE_DOUBLE as return and argument type for FADD
> >
> > Or it has to be narrowed down by zeroing down the trailing
> > out-of-precision bits?
> > Also, if the addition or any one of the argument exceeds the return
> > size, the integer part of the addition would not fit in the narrowed
> > type. Like, 2^32 would easily fit in double but will lose its least
> > significant bit in float and become 2^31. How these types are supposed
> > to be handled?
> >
> > Thanks,
> > -Tejas

fadd.diff (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [GSoC-19] Implementing narrowing functions like fadd

Richard Sandiford-9
Tejas Joshi <[hidden email]> writes:

> Hello.
> I have added fadd variants in builtins.def. For fadd and faddl
> variants, I had to introduce builtin function types in
> builtin-types.def :
>
> +DEF_FUNCTION_TYPE_2 (BT_FN_FLOAT_DOUBLE_DOUBLE,
> +                    BT_FLOAT, BT_DOUBLE, BT_DOUBLE)
> +DEF_FUNCTION_TYPE_2 (BT_FN_FLOAT_LONGDOUBLE_LONGDOUBLE,
> +                    BT_FLOAT, BT_LONGDOUBLE, BT_LONGDOUBLE)
>
> and used them to define function in builtins.def. At this point, only
> faddf variant is getting called by test program :
>
> int main ()
> {
>     double z = __builtin_faddf (3.5, 1.4);
> }
> faddf variant is using BT_FN_FLOAT_FLOAT_FLOAT which is already
> defined in builtin-types.def means I need not to introduce it. Why
> fadd and faddl are not getting called in this patch? I don't find any
> other place where these function types needs to be added.

This is because of:

  if (mode == arg0_mode
      && real_cst_p (arg0)
      && real_cst_p (arg1))

in fold_const_call_1.  The reason for that check is that usually
the format passed in to fold_const_call_sss applies to both arguments
and the return type.  There's already an exception for CASE_CFN_NEXTTOWARD
though.  I guess you'll need something similar here.

Thanks,
Richard
Reply | Threaded
Open this post in threaded view
|

Re: [GSoC-19] Implementing narrowing functions like fadd

Tejas Joshi
Hi all,
I have some doubts regarding narrowing functions. Functions like fadd
have different variants like fadd, faddl and daddl. These functions
differs from general floating point functions which have float and
long double argument types. These functions are defined in
builtins.def like floor, floorf and floorl with their respective
macros BUILT_IN_FLOOR, BUILT_IN_FLOORF and BUILT_IN_FLOORL. But for
fadd, fsub, fmul variants, float is not supposed to be one of the
argument types.

Also, CASE_MATHFN and CASE_MATHFN_FLOATN cases in builtins.c expand
normal, F and L variants which are assigned to respective fcode
built_in_function. This makes any function defined in builtins.def to
have F and L variants mandatory. How these narrowing functions are
supposed to be handled? Do we define another macro expansion like
CASE_MATHFN or have a manual case handling in mathfn_built_in_2?
Attached patch is what I have tried so far.

Thanks,
Tejas

On Wed, 10 Jul 2019 at 18:03, Richard Sandiford
<[hidden email]> wrote:

>
> Tejas Joshi <[hidden email]> writes:
> > Hello.
> > I have added fadd variants in builtins.def. For fadd and faddl
> > variants, I had to introduce builtin function types in
> > builtin-types.def :
> >
> > +DEF_FUNCTION_TYPE_2 (BT_FN_FLOAT_DOUBLE_DOUBLE,
> > +                    BT_FLOAT, BT_DOUBLE, BT_DOUBLE)
> > +DEF_FUNCTION_TYPE_2 (BT_FN_FLOAT_LONGDOUBLE_LONGDOUBLE,
> > +                    BT_FLOAT, BT_LONGDOUBLE, BT_LONGDOUBLE)
> >
> > and used them to define function in builtins.def. At this point, only
> > faddf variant is getting called by test program :
> >
> > int main ()
> > {
> >     double z = __builtin_faddf (3.5, 1.4);
> > }
> > faddf variant is using BT_FN_FLOAT_FLOAT_FLOAT which is already
> > defined in builtin-types.def means I need not to introduce it. Why
> > fadd and faddl are not getting called in this patch? I don't find any
> > other place where these function types needs to be added.
>
> This is because of:
>
>   if (mode == arg0_mode
>       && real_cst_p (arg0)
>       && real_cst_p (arg1))
>
> in fold_const_call_1.  The reason for that check is that usually
> the format passed in to fold_const_call_sss applies to both arguments
> and the return type.  There's already an exception for CASE_CFN_NEXTTOWARD
> though.  I guess you'll need something similar here.
>
> Thanks,
> Richard

fadd.diff (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [GSoC-19] Implementing narrowing functions like fadd

Joseph Myers
On Tue, 23 Jul 2019, Tejas Joshi wrote:

> Also, CASE_MATHFN and CASE_MATHFN_FLOATN cases in builtins.c expand
> normal, F and L variants which are assigned to respective fcode
> built_in_function. This makes any function defined in builtins.def to
> have F and L variants mandatory. How these narrowing functions are
> supposed to be handled? Do we define another macro expansion like
> CASE_MATHFN or have a manual case handling in mathfn_built_in_2?
> Attached patch is what I have tried so far.

You'll need something different from CASE_MATHFN - these are a different
kind of functions that need handling in a different way, because they are
parametrized over certain *pairs* of types, rather than over a single
type.

(The main case for these being built-in is probably not folding for
constant arguments - it's generating appropriate instructions when
building with -fno-math-errno for processors that have appropriate
narrowing instructions, such as Power ISA 2.07 or later, which I think
means POWER8 or later.)

--
Joseph S. Myers
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [GSoC-19] Implementing narrowing functions like fadd

Tejas Joshi
In reply to this post by Tejas Joshi
Hello.

>> You'll need something different from CASE_MATHFN - these are a different
>> kind of functions that need handling in a different way, because they are
>> parametrized over certain *pairs* of types, rather than over a single
>> type.
> first phase, please just directly test for in the code for
> CFN_BUILT_IN_FADD, CFN_BUILT_IN_FADDL, CFN_BUILT_IN_DADDL and process
> those here to get a prototype working.  When you add support for more

Thanks for the inputs. I have used CFN_BUILT_IN_FADD, etc in this
following patch and function is getting folded.
My question is that how the addition and narrowing should be performed
(is it ok to use do_add for addition?). As functions in real.c does
not operate on any specific precision, just defining the return type
as float would do the trick? Or do I need to make trailing
out-of-precision bits zero? If yes, having functions like
double_to_float would then be useful or such functions already exist
to do the conversion?

Thanks,
Tejas


On Fri, 26 Jul 2019 at 22:49, Martin Jambor <[hidden email]> wrote:

>
> Hello Tejas,
>
> On Tue, Jul 23 2019, Tejas Joshi wrote:
> > Hi all,
> > I have some doubts regarding narrowing functions. Functions like fadd
> > have different variants like fadd, faddl and daddl. These functions
> > differs from general floating point functions which have float and
> > long double argument types. These functions are defined in
> > builtins.def like floor, floorf and floorl with their respective
> > macros BUILT_IN_FLOOR, BUILT_IN_FLOORF and BUILT_IN_FLOORL. But for
> > fadd, fsub, fmul variants, float is not supposed to be one of the
> > argument types.
> >
> > Also, CASE_MATHFN and CASE_MATHFN_FLOATN cases in builtins.c expand
> > normal, F and L variants which are assigned to respective fcode
> > built_in_function. This makes any function defined in builtins.def to
> > have F and L variants mandatory. How these narrowing functions are
> > supposed to be handled? Do we define another macro expansion like
> > CASE_MATHFN or have a manual case handling in mathfn_built_in_2?
> > Attached patch is what I have tried so far.
>
> They are different so as Joseph pointed out, they need to be handled
> differently, don't feel too constrained by the patterns already in gcc.
> For now you can even just just use directly the constants
> CFN_BUILT_IN_FADD, CFN_BUILT_IN_FADDL, CFN_BUILT_IN_DADDL in the code to
> get a prototype working and then set out to create a macro to wrap this
> in, perhaps even only after you added support for two or more such
> narrowing instructions so that you see how the common parts look like.
>
>
> > diff --git a/gcc/builtins.c b/gcc/builtins.c
> > index 8ceb077b0bf..37c4206ec65 100644
> > --- a/gcc/builtins.c
> > +++ b/gcc/builtins.c
> > @@ -2006,6 +2006,7 @@ mathfn_built_in_2 (tree type, combined_fn fn)
> >      CASE_MATHFN (EXP2)
> >      CASE_MATHFN (EXPM1)
> >      CASE_MATHFN (FABS)
> > +    CASE_MATHFN (FADD)
> >      CASE_MATHFN (FDIM)
> >      CASE_MATHFN_FLOATN (FLOOR)
> >      CASE_MATHFN_FLOATN (FMA)
>
> This does not seem to be necessary for folding, or am I wrong?  If it is
> intended for expansion, I'd drop it from this patch and move to the one
> where it is required.
>
>
>
> > diff --git a/gcc/builtins.def b/gcc/builtins.def
> > index 8bb7027aac7..2e749f038be 100644
> > --- a/gcc/builtins.def
> > +++ b/gcc/builtins.def
> > @@ -352,6 +352,12 @@ DEF_C99_C90RES_BUILTIN (BUILT_IN_FABSL, "fabsl", BT_FN_LONGDOUBLE_LONGDOUBLE, AT
> >  #define FABS_TYPE(F) BT_FN_##F##_##F
> >  DEF_EXT_LIB_FLOATN_NX_BUILTINS (BUILT_IN_FABS, "fabs", FABS_TYPE, ATTR_CONST_NOTHROW_LEAF_LIST)
> >  #undef FABS_TYPE
> > +DEF_EXT_LIB_BUILTIN    (BUILT_IN_FADD, "fadd", BT_FN_FLOAT_DOUBLE_DOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
> > +DEF_EXT_LIB_BUILTIN    (BUILT_IN_DADDL, "daddl", BT_FN_DOUBLE_LONGDOUBLE_LONGDOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
> > +DEF_EXT_LIB_BUILTIN    (BUILT_IN_FADDL, "faddl", BT_FN_FLOAT_LONGDOUBLE_LONGDOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
> > +#define FADD_TYPE(F) BT_FN_##F##_##F##_##F
> > +DEF_EXT_LIB_FLOATN_NX_BUILTINS (BUILT_IN_FADD, "fadd", FADD_TYPE, ATTR_CONST_NOTHROW_LEAF_LIST)
> > +#undef FADD_TYPE
>
> This results into definitions like BUILT_IN_FADDF32 (what would that
> do?)  and BUILT_IN_FADDF64 or BUILT_IN_FADDF128 (which I don't think we
> want, Joseph?).  Perhaps you can just simply drop this use of
> DEF_EXT_LIB_FLOATN_NX_BUILTINS?
>
> >  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)
> > diff --git a/gcc/fold-const-call.c b/gcc/fold-const-call.c
> > index d9b546e6803..9f0e5510514 100644
> > --- a/gcc/fold-const-call.c
> > +++ b/gcc/fold-const-call.c
> > @@ -570,6 +570,16 @@ fold_const_nextafter (real_value *result, const real_value *arg0,
> >    return true;
> >  }
> >
> > +static bool
> > +fold_const_fadd (real_value* result, const real_value *arg0,
> > +              const real_value *arg1, const real_format *format)
> > +{
> > +  if (!real_fadd(result, format, arg0, arg1))
> > +    return true;
> > +  else
> > +    return false;
> > +}
> > +
> >  /* Try to evaluate:
> >
> >        *RESULT = ldexp (*ARG0, ARG1)
> > @@ -1366,6 +1376,9 @@ fold_const_call_sss (real_value *result, combined_fn fn,
> >      CASE_CFN_NEXTTOWARD:
> >        return fold_const_nextafter (result, arg0, arg1, format);
> >
> > +    CASE_CFN_FADD:
> > +      return fold_const_fadd (result, arg0, arg1, format);
> > +
>
> As you have pointed out, this does not work, this is not expanded into a
> macro and is just as an unused label for which you get a warning.
> Moreover...
>
> >      default:
> >        return false;
> >      }
> > @@ -1500,6 +1513,20 @@ fold_const_call_1 (combined_fn fn, tree type, tree arg0, tree arg1)
> >         }
> >        return NULL_TREE;
> >      }
> > +  else if (mode != arg0_mode
> > +       && real_cst_p (arg0)
> > +       && real_cst_p (arg1))
> > +    {
> > +      gcc_checking_assert (SCALAR_FLOAT_MODE_P (arg0_mode));
> > +      REAL_VALUE_TYPE result;
> > +      if (arg0_mode == arg1_mode)
> > +     {
> > +       if (fold_const_call_sss (&result, fn, TREE_REAL_CST_PTR (arg0),
> > +                                  TREE_REAL_CST_PTR (arg1),
> > +                                  REAL_MODE_FORMAT (mode)))
>
> ...I don't think you want to stuff handling narrowing functions into
> fold_const_call_sss, that is for operations with matching type.  In the
> first phase, please just directly test for in the code for
> CFN_BUILT_IN_FADD, CFN_BUILT_IN_FADDL, CFN_BUILT_IN_DADDL and process
> those here to get a prototype working.  When you add support for more
> narrowing functions we can then move their processing into a new
> separate function.
>
> At leat that is how I would proceed with folding.
>
> Thanks,
>
> Martin

fadd-1.diff (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [GSoC-19] Implementing narrowing functions like fadd

Martin Jambor-3
Hi,

On Sat, Jul 27 2019, Tejas Joshi wrote:

> Hello.
>
>>> You'll need something different from CASE_MATHFN - these are a different
>>> kind of functions that need handling in a different way, because they are
>>> parametrized over certain *pairs* of types, rather than over a single
>>> type.
>> first phase, please just directly test for in the code for
>> CFN_BUILT_IN_FADD, CFN_BUILT_IN_FADDL, CFN_BUILT_IN_DADDL and process
>> those here to get a prototype working.  When you add support for more
>
> Thanks for the inputs. I have used CFN_BUILT_IN_FADD, etc in this
> following patch and function is getting folded.

good.  Please add comments to functions which miss them (real_fadd and
fold_const_fadd), for example I am not sure what the return values are
supposed to mean, and add a run-time testcase(s) and I'd say you are
done for now - after you implement fsub, fmul and fdiv(?) you might want
to re-structure some common bits to make the code prettier.

> My question is that how the addition and narrowing should be performed
> (is it ok to use do_add for addition?).

I don't see a reason why it would not be.

> As functions in real.c does
> not operate on any specific precision, just defining the return type
> as float would do the trick? Or do I need to make trailing
> out-of-precision bits zero? If yes, having functions like
> double_to_float would then be useful or such functions already exist
> to do the conversion?

I am not sure I understand your question, you have used real_convert in
real_fadd and it seems to be doing exactly that?  As you know I am not
too familiar with this area of gcc but reading the code suggests that
and a simple debugging session seems to confirm that (some unimportant
gdb output omitted):

----------------------------------------------------------------------
$ ~/gcc/gsoc/inst/bin/gcc -Ofast -S fadd-fold.c -wrapper gdb,--args
GNU gdb (GDB; openSUSE Tumbleweed) 8.3
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

(gdb) b real_fadd
Breakpoint 1 at 0x108215b: file /home/mjambor/gcc/gsoc/src/gcc/real.c, line 5100.
(gdb) r
Starting program: /home/mjambor/gcc/gsoc/inst/lib/gcc/x86_64-pc-linux-gnu/10.0.0/cc1 -quiet fadd-fold.c -quiet -dumpbase fadd-fold.c -mtune=generic -march=x86-64 -auxbase fadd-fold -Ofast -o fadd-fold.s

Breakpoint 1, real_fadd (r=0x7fffffffc580, fmt=..., x=0x7ffff7800060, y=0x7ffff7800080)
    at /home/mjambor/gcc/gsoc/src/gcc/real.c:5100
5100      do_add (r, x, y, 0);
(gdb) n
5101      if (fmt)
(gdb) p *r
$1 = {cl = 1, decimal = 0, sign = 0, signalling = 0, canonical = 0, uexp = 5, sig = {0, 0,
    10549231767152649216}}
(gdb) p/x r->sig[2]
$2 = 0x9266666666666400
(gdb) n
5102        real_convert (r, fmt, r);
(gdb)
5103      return false;
(gdb) p/x r->sig[2]
$3 = 0x9266660000000000
----------------------------------------------------------------------

Thanks,

Martin


Reply | Threaded
Open this post in threaded view
|

Re: [GSoC-19] Implementing narrowing functions like fadd

Tejas Joshi
Hello.

> fold_const_fadd), for example I am not sure what the return values are
> supposed to mean, and add a run-time testcase(s) and I'd say you are
> done for now

I modeled real_fadd function on a similar function, real_nextafter
which would take three arguments. Just as overflow and underflow
conditions are handled there, I thought similarly if exact/inexact and
overflow/underflow conditions would be handled by fold_const_fadd for
real_fadd. As these conditions are still need to be addressed (so
current function is prototypish), is real_nextafter a good model to
refer?

> I am not sure I understand your question, you have used real_convert in
> real_fadd and it seems to be doing exactly that?  As you know I am not

Looking at different comments where real_convert is used, I guessed it
formats GCC's floating point format to a target format rather than
converting to return type. Its still unclear to me but its good if it
does convert to return type like it seems. I am working on these
conditions now and will try to come up with testcases.

Thanks,
Tejas


On Mon, 29 Jul 2019 at 22:47, Martin Jambor <[hidden email]> wrote:

>
> Hi,
>
> On Sat, Jul 27 2019, Tejas Joshi wrote:
> > Hello.
> >
> >>> You'll need something different from CASE_MATHFN - these are a different
> >>> kind of functions that need handling in a different way, because they are
> >>> parametrized over certain *pairs* of types, rather than over a single
> >>> type.
> >> first phase, please just directly test for in the code for
> >> CFN_BUILT_IN_FADD, CFN_BUILT_IN_FADDL, CFN_BUILT_IN_DADDL and process
> >> those here to get a prototype working.  When you add support for more
> >
> > Thanks for the inputs. I have used CFN_BUILT_IN_FADD, etc in this
> > following patch and function is getting folded.
>
> good.  Please add comments to functions which miss them (real_fadd and
> fold_const_fadd), for example I am not sure what the return values are
> supposed to mean, and add a run-time testcase(s) and I'd say you are
> done for now - after you implement fsub, fmul and fdiv(?) you might want
> to re-structure some common bits to make the code prettier.
>
> > My question is that how the addition and narrowing should be performed
> > (is it ok to use do_add for addition?).
>
> I don't see a reason why it would not be.
>
> > As functions in real.c does
> > not operate on any specific precision, just defining the return type
> > as float would do the trick? Or do I need to make trailing
> > out-of-precision bits zero? If yes, having functions like
> > double_to_float would then be useful or such functions already exist
> > to do the conversion?
>
> I am not sure I understand your question, you have used real_convert in
> real_fadd and it seems to be doing exactly that?  As you know I am not
> too familiar with this area of gcc but reading the code suggests that
> and a simple debugging session seems to confirm that (some unimportant
> gdb output omitted):
>
> ----------------------------------------------------------------------
> $ ~/gcc/gsoc/inst/bin/gcc -Ofast -S fadd-fold.c -wrapper gdb,--args
> GNU gdb (GDB; openSUSE Tumbleweed) 8.3
> Copyright (C) 2019 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
>
> (gdb) b real_fadd
> Breakpoint 1 at 0x108215b: file /home/mjambor/gcc/gsoc/src/gcc/real.c, line 5100.
> (gdb) r
> Starting program: /home/mjambor/gcc/gsoc/inst/lib/gcc/x86_64-pc-linux-gnu/10.0.0/cc1 -quiet fadd-fold.c -quiet -dumpbase fadd-fold.c -mtune=generic -march=x86-64 -auxbase fadd-fold -Ofast -o fadd-fold.s
>
> Breakpoint 1, real_fadd (r=0x7fffffffc580, fmt=..., x=0x7ffff7800060, y=0x7ffff7800080)
>     at /home/mjambor/gcc/gsoc/src/gcc/real.c:5100
> 5100      do_add (r, x, y, 0);
> (gdb) n
> 5101      if (fmt)
> (gdb) p *r
> $1 = {cl = 1, decimal = 0, sign = 0, signalling = 0, canonical = 0, uexp = 5, sig = {0, 0,
>     10549231767152649216}}
> (gdb) p/x r->sig[2]
> $2 = 0x9266666666666400
> (gdb) n
> 5102        real_convert (r, fmt, r);
> (gdb)
> 5103      return false;
> (gdb) p/x r->sig[2]
> $3 = 0x9266660000000000
> ----------------------------------------------------------------------
>
> Thanks,
>
> Martin
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [GSoC-19] Implementing narrowing functions like fadd

Tejas Joshi
Hello.
I have made this patch strictly considering the following points
Joseph mentioned in his initial email :

> * The narrowing functions, e.g. fadd, faddl, daddl, are a bit different
> from most other built-in math.h functions because the return type is
> different from the argument types.  You could start by adding them to
> builtins.def similarly to roundeven (with new macros to handle adding such
> functions for relevant pairs of _FloatN, _FloatNx types).  These functions
> could be folded for constant arguments only if the result is exact, or if
> -fno-rounding-math -fno-trapping-math (and -fno-math-errno if the result
> involves overflow / underflow).

I am trying to come up with testcases which would work around
-fno-rounding-math -fno-trapping-math and -fno-math-errno while
considering inexact and overlfow/underflow cases. I will try them as
soon as possible and send another patch with them and after regression
testing. Apart from that, am I missing something in this patch?

Thanks,
Tejas


On Wed, 31 Jul 2019 at 12:06, Tejas Joshi <[hidden email]> wrote:

>
> Hello.
>
> > fold_const_fadd), for example I am not sure what the return values are
> > supposed to mean, and add a run-time testcase(s) and I'd say you are
> > done for now
>
> I modeled real_fadd function on a similar function, real_nextafter
> which would take three arguments. Just as overflow and underflow
> conditions are handled there, I thought similarly if exact/inexact and
> overflow/underflow conditions would be handled by fold_const_fadd for
> real_fadd. As these conditions are still need to be addressed (so
> current function is prototypish), is real_nextafter a good model to
> refer?
>
> > I am not sure I understand your question, you have used real_convert in
> > real_fadd and it seems to be doing exactly that?  As you know I am not
>
> Looking at different comments where real_convert is used, I guessed it
> formats GCC's floating point format to a target format rather than
> converting to return type. Its still unclear to me but its good if it
> does convert to return type like it seems. I am working on these
> conditions now and will try to come up with testcases.
>
> Thanks,
> Tejas
>
>
> On Mon, 29 Jul 2019 at 22:47, Martin Jambor <[hidden email]> wrote:
> >
> > Hi,
> >
> > On Sat, Jul 27 2019, Tejas Joshi wrote:
> > > Hello.
> > >
> > >>> You'll need something different from CASE_MATHFN - these are a different
> > >>> kind of functions that need handling in a different way, because they are
> > >>> parametrized over certain *pairs* of types, rather than over a single
> > >>> type.
> > >> first phase, please just directly test for in the code for
> > >> CFN_BUILT_IN_FADD, CFN_BUILT_IN_FADDL, CFN_BUILT_IN_DADDL and process
> > >> those here to get a prototype working.  When you add support for more
> > >
> > > Thanks for the inputs. I have used CFN_BUILT_IN_FADD, etc in this
> > > following patch and function is getting folded.
> >
> > good.  Please add comments to functions which miss them (real_fadd and
> > fold_const_fadd), for example I am not sure what the return values are
> > supposed to mean, and add a run-time testcase(s) and I'd say you are
> > done for now - after you implement fsub, fmul and fdiv(?) you might want
> > to re-structure some common bits to make the code prettier.
> >
> > > My question is that how the addition and narrowing should be performed
> > > (is it ok to use do_add for addition?).
> >
> > I don't see a reason why it would not be.
> >
> > > As functions in real.c does
> > > not operate on any specific precision, just defining the return type
> > > as float would do the trick? Or do I need to make trailing
> > > out-of-precision bits zero? If yes, having functions like
> > > double_to_float would then be useful or such functions already exist
> > > to do the conversion?
> >
> > I am not sure I understand your question, you have used real_convert in
> > real_fadd and it seems to be doing exactly that?  As you know I am not
> > too familiar with this area of gcc but reading the code suggests that
> > and a simple debugging session seems to confirm that (some unimportant
> > gdb output omitted):
> >
> > ----------------------------------------------------------------------
> > $ ~/gcc/gsoc/inst/bin/gcc -Ofast -S fadd-fold.c -wrapper gdb,--args
> > GNU gdb (GDB; openSUSE Tumbleweed) 8.3
> > Copyright (C) 2019 Free Software Foundation, Inc.
> > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> >
> > (gdb) b real_fadd
> > Breakpoint 1 at 0x108215b: file /home/mjambor/gcc/gsoc/src/gcc/real.c, line 5100.
> > (gdb) r
> > Starting program: /home/mjambor/gcc/gsoc/inst/lib/gcc/x86_64-pc-linux-gnu/10.0.0/cc1 -quiet fadd-fold.c -quiet -dumpbase fadd-fold.c -mtune=generic -march=x86-64 -auxbase fadd-fold -Ofast -o fadd-fold.s
> >
> > Breakpoint 1, real_fadd (r=0x7fffffffc580, fmt=..., x=0x7ffff7800060, y=0x7ffff7800080)
> >     at /home/mjambor/gcc/gsoc/src/gcc/real.c:5100
> > 5100      do_add (r, x, y, 0);
> > (gdb) n
> > 5101      if (fmt)
> > (gdb) p *r
> > $1 = {cl = 1, decimal = 0, sign = 0, signalling = 0, canonical = 0, uexp = 5, sig = {0, 0,
> >     10549231767152649216}}
> > (gdb) p/x r->sig[2]
> > $2 = 0x9266666666666400
> > (gdb) n
> > 5102        real_convert (r, fmt, r);
> > (gdb)
> > 5103      return false;
> > (gdb) p/x r->sig[2]
> > $3 = 0x9266660000000000
> > ----------------------------------------------------------------------
> >
> > Thanks,
> >
> > Martin
> >
> >

fadd.diff (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [GSoC-19] Implementing narrowing functions like fadd

Tejas Joshi
Hello.
I have come up with the testcases for fadd variants and the following
patch comes with them. Again, the patch follows the points mentioned
above and if good to go, I will post it to the gcc-patches. The patch
bootstraps and survives regression tests.

Thanks,
Tejas

On Fri, 2 Aug 2019 at 16:10, Tejas Joshi <[hidden email]> wrote:

>
> Hello.
> I have made this patch strictly considering the following points
> Joseph mentioned in his initial email :
>
> > * The narrowing functions, e.g. fadd, faddl, daddl, are a bit different
> > from most other built-in math.h functions because the return type is
> > different from the argument types.  You could start by adding them to
> > builtins.def similarly to roundeven (with new macros to handle adding such
> > functions for relevant pairs of _FloatN, _FloatNx types).  These functions
> > could be folded for constant arguments only if the result is exact, or if
> > -fno-rounding-math -fno-trapping-math (and -fno-math-errno if the result
> > involves overflow / underflow).
>
> I am trying to come up with testcases which would work around
> -fno-rounding-math -fno-trapping-math and -fno-math-errno while
> considering inexact and overlfow/underflow cases. I will try them as
> soon as possible and send another patch with them and after regression
> testing. Apart from that, am I missing something in this patch?
>
> Thanks,
> Tejas
>
>
> On Wed, 31 Jul 2019 at 12:06, Tejas Joshi <[hidden email]> wrote:
> >
> > Hello.
> >
> > > fold_const_fadd), for example I am not sure what the return values are
> > > supposed to mean, and add a run-time testcase(s) and I'd say you are
> > > done for now
> >
> > I modeled real_fadd function on a similar function, real_nextafter
> > which would take three arguments. Just as overflow and underflow
> > conditions are handled there, I thought similarly if exact/inexact and
> > overflow/underflow conditions would be handled by fold_const_fadd for
> > real_fadd. As these conditions are still need to be addressed (so
> > current function is prototypish), is real_nextafter a good model to
> > refer?
> >
> > > I am not sure I understand your question, you have used real_convert in
> > > real_fadd and it seems to be doing exactly that?  As you know I am not
> >
> > Looking at different comments where real_convert is used, I guessed it
> > formats GCC's floating point format to a target format rather than
> > converting to return type. Its still unclear to me but its good if it
> > does convert to return type like it seems. I am working on these
> > conditions now and will try to come up with testcases.
> >
> > Thanks,
> > Tejas
> >
> >
> > On Mon, 29 Jul 2019 at 22:47, Martin Jambor <[hidden email]> wrote:
> > >
> > > Hi,
> > >
> > > On Sat, Jul 27 2019, Tejas Joshi wrote:
> > > > Hello.
> > > >
> > > >>> You'll need something different from CASE_MATHFN - these are a different
> > > >>> kind of functions that need handling in a different way, because they are
> > > >>> parametrized over certain *pairs* of types, rather than over a single
> > > >>> type.
> > > >> first phase, please just directly test for in the code for
> > > >> CFN_BUILT_IN_FADD, CFN_BUILT_IN_FADDL, CFN_BUILT_IN_DADDL and process
> > > >> those here to get a prototype working.  When you add support for more
> > > >
> > > > Thanks for the inputs. I have used CFN_BUILT_IN_FADD, etc in this
> > > > following patch and function is getting folded.
> > >
> > > good.  Please add comments to functions which miss them (real_fadd and
> > > fold_const_fadd), for example I am not sure what the return values are
> > > supposed to mean, and add a run-time testcase(s) and I'd say you are
> > > done for now - after you implement fsub, fmul and fdiv(?) you might want
> > > to re-structure some common bits to make the code prettier.
> > >
> > > > My question is that how the addition and narrowing should be performed
> > > > (is it ok to use do_add for addition?).
> > >
> > > I don't see a reason why it would not be.
> > >
> > > > As functions in real.c does
> > > > not operate on any specific precision, just defining the return type
> > > > as float would do the trick? Or do I need to make trailing
> > > > out-of-precision bits zero? If yes, having functions like
> > > > double_to_float would then be useful or such functions already exist
> > > > to do the conversion?
> > >
> > > I am not sure I understand your question, you have used real_convert in
> > > real_fadd and it seems to be doing exactly that?  As you know I am not
> > > too familiar with this area of gcc but reading the code suggests that
> > > and a simple debugging session seems to confirm that (some unimportant
> > > gdb output omitted):
> > >
> > > ----------------------------------------------------------------------
> > > $ ~/gcc/gsoc/inst/bin/gcc -Ofast -S fadd-fold.c -wrapper gdb,--args
> > > GNU gdb (GDB; openSUSE Tumbleweed) 8.3
> > > Copyright (C) 2019 Free Software Foundation, Inc.
> > > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> > >
> > > (gdb) b real_fadd
> > > Breakpoint 1 at 0x108215b: file /home/mjambor/gcc/gsoc/src/gcc/real.c, line 5100.
> > > (gdb) r
> > > Starting program: /home/mjambor/gcc/gsoc/inst/lib/gcc/x86_64-pc-linux-gnu/10.0.0/cc1 -quiet fadd-fold.c -quiet -dumpbase fadd-fold.c -mtune=generic -march=x86-64 -auxbase fadd-fold -Ofast -o fadd-fold.s
> > >
> > > Breakpoint 1, real_fadd (r=0x7fffffffc580, fmt=..., x=0x7ffff7800060, y=0x7ffff7800080)
> > >     at /home/mjambor/gcc/gsoc/src/gcc/real.c:5100
> > > 5100      do_add (r, x, y, 0);
> > > (gdb) n
> > > 5101      if (fmt)
> > > (gdb) p *r
> > > $1 = {cl = 1, decimal = 0, sign = 0, signalling = 0, canonical = 0, uexp = 5, sig = {0, 0,
> > >     10549231767152649216}}
> > > (gdb) p/x r->sig[2]
> > > $2 = 0x9266666666666400
> > > (gdb) n
> > > 5102        real_convert (r, fmt, r);
> > > (gdb)
> > > 5103      return false;
> > > (gdb) p/x r->sig[2]
> > > $3 = 0x9266660000000000
> > > ----------------------------------------------------------------------
> > >
> > > Thanks,
> > >
> > > Martin
> > >
> > >

fadd-2.diff (10K) Download Attachment