Re: About GSOC.

[Tejas Joshi]

Hello.
I've been inactive for some time due to exams but I have been studying
the real.h and IEEE 754 floating point format as far as I could.

> floating-point built-in functions.  That means you should instead
> understand REAL_EXP and the significands of floating-point values, and

In GCC's representation of REAL or may I say floating point numbers
(including decimal floating point values), values are defined in
macros in real.h like

#define SIGNIFICAND_BITS(128 + HOST_BITS_PER_LONG)   (why
128+host-bits_per_long?, even quad precision has total 128 bits.)
#define EXP_BITS(32 - 6)

This include EXP_BITS resolving to I believe, exponent bits and macro
REAL_EXP to exponent value which determines the value of the exponent
of REAL r, which is passed in real.c with mathematical calculations
like XOR and shifting (multiplication by 2) though the operation is
unclear. (Adding comment to these will also be helpful in a patch for
me!)

> true that it doesn't have a comment specifying its semantics directly, but
> the /* ENUM_BITFIELD (real_value_class) */ should give a strong hint,
> along with the values that are stored in that field.  By looking at how

As far as the struct real_value is concerned, I believe the values
associated with decimal, sign, etc are used for handling switch
conditions in functions of real.c and then carrying out specific
functions like clear_signifcand_below.
Relating to enumeration real_value_class, it determines the type of
the number like nan or normal in the functions. Though, attributes of
struct real_value are pretty unclear to me regarding to the number it
represents. (Am I right within this grasp?).
Thank you.

Regards,
-Tejas
On Fri, 16 Nov 2018 at
22:20, Joseph Myers <mailto:jos...@codesourcery.com";
target="_blank">jos...@codesourcery.com>
wrote:On Fri, 16 Nov 2018, Tejas Joshi wrote:

> About roundeven, there might be need to add case to
> expand_builtin_int_roundingfn similar to
> ceil, for expansion.
> But how is round() expanded since there's no
> entry for it in expand_builtin_int_roundingfn ?

Please see the comment above expand_builtin_int_roundingfn, and that above 
expand_builtin_int_roundingfn_2, which handle different sets of
functions.  
Those functions are of no relevance to adding support for built-in 
roundeven.  (They might be of relevance to support for built-in fromfp 
functions, depending on whether the detailed semantics allows 
casts-to-integer of calls to other functions to be converted into calls to 
the fromfp functions.  But I don't think inventing
__builtin_lroundeven 
would be appropriate.)

> Also, is it right to have an added case for roundeven in convert.c
> along CASE_FLT_FN (BUILT_IN_ROUND)
> in convert_to_integer_1?

Not until doing things with fromfp functions.  There is no
lroundeven (for 
example) in TS 18661-1.

-- 
Joseph S. Myers
mailto:jos...@codesourcery.com";
target="_blank">jos...@codesourcery.com

Re: About GSOC.

[Tejas Joshi]

> differ.  (It's the unoptimized, stage1 cc1 that should be run under a
> debugger.  See <https://gcc.gnu.org/wiki/DebuggingGCC> for more details.)

Hello.
I normally configure GCC by (as you told)

/configure --enable-languages=c,c++ --disable-bootstrap --disable-multilib

And further as told in <https://gcc.gnu.org/wiki/DebuggingGCC>

make STAGE1_CXXFLAGS="-g -O0" all-stage1

but instead of -g to use -g3 is suggested for making macros debuggable
and then use GDB.
May I proceed the same?

On Tue, 22 Jan 2019 at 04:33, Joseph Myers  wrote:
>
> On Tue, 22 Jan 2019, Tejas Joshi wrote:
>
> > the number like nan or normal in the functions. Though, attributes of
> > struct real_value are pretty unclear to me regarding to the number it
> > represents. (Am I right within this grasp?).
>
> It may be helpful to run the compiler under a debugger to examine how
> particular real numbers are represented in real_value - that should help
> answer questions such as what endianness is used for the significand, or
> whether floating point values with a given exponent are in the range
> [2^EXP, 2^(EXP+1)) or [2^(EXP-1), 2^EXP), where conventions commonly
> differ.  (It's the unoptimized, stage1 cc1 that should be run under a
> debugger.  See <https://gcc.gnu.org/wiki/DebuggingGCC> for more details.)
>
> And of course contribute comments in real.h once you've determined the
> answers - because there are such areas where conventions about
> representation of floating-point numbers commonly differ, it's
> particularly valuable to have such comments because even someone familiar
> with floating-point won't know which convention has been chosen by this
> code in GCC.
>
> --
> Joseph S. Myers
> jos...@codesourcery.com

Re: About GSOC.

[Tejas Joshi]

I built gcc as a debuggable compiler as given using -g3. I am using
gdb and loaded the cc1 using:

gdb --args cc1

with output as:

Successfully loaded GDB hooks for GCC

But I really dont know how to inspect a file like real.h (real_value)/real.c?

Thanks.
-Tejas

On Wed, 23 Jan 2019 at 08:28, Tejas Joshi  wrote:
>
> > differ.  (It's the unoptimized, stage1 cc1 that should be run under a
> > debugger.  See <https://gcc.gnu.org/wiki/DebuggingGCC> for more details.)
>
> Hello.
> I normally configure GCC by (as you told)
>
> /configure --enable-languages=c,c++ --disable-bootstrap --disable-multilib
>
> And further as told in <https://gcc.gnu.org/wiki/DebuggingGCC>
>
> make STAGE1_CXXFLAGS="-g -O0" all-stage1
>
> but instead of -g to use -g3 is suggested for making macros debuggable
> and then use GDB.
> May I proceed the same?
>
> On Tue, 22 Jan 2019 at 04:33, Joseph Myers  wrote:
> >
> > On Tue, 22 Jan 2019, Tejas Joshi wrote:
> >
> > > the number like nan or normal in the functions. Though, attributes of
> > > struct real_value are pretty unclear to me regarding to the number it
> > > represents. (Am I right within this grasp?).
> >
> > It may be helpful to run the compiler under a debugger to examine how
> > particular real numbers are represented in real_value - that should help
> > answer questions such as what endianness is used for the significand, or
> > whether floating point values with a given exponent are in the range
> > [2^EXP, 2^(EXP+1)) or [2^(EXP-1), 2^EXP), where conventions commonly
> > differ.  (It's the unoptimized, stage1 cc1 that should be run under a
> > debugger.  See <https://gcc.gnu.org/wiki/DebuggingGCC> for more details.)
> >
> > And of course contribute comments in real.h once you've determined the
> > answers - because there are such areas where conventions about
> > representation of floating-point numbers commonly differ, it's
> > particularly valuable to have such comments because even someone familiar
> > with floating-point won't know which convention has been chosen by this
> > code in GCC.
> >
> > --
> > Joseph S. Myers
> > jos...@codesourcery.com

Re: About GSOC.

[Tejas Joshi]

It took some time to get know using GDB, but upto some end I got it to
work. The enum real_value_class is used to classify the number into
zero, normal, infinity and NaN.
This class is represented by r->cl in real_value and values in struct
real_value are used as flags or representations while string to real
conversion (real_from_string) in real.c and other functions. The
decimal/hex string value is converted into real in real_from_string
function with byte-byte comparison which also include mpfr. (Correct
me if I am wrong.) What is the significance of mpfr related to these
internal representations?
Thanks.

-Tejas

On Wed, 23 Jan 2019 at 23:06, Joseph Myers  wrote:
>
> On Wed, 23 Jan 2019, Tejas Joshi wrote:
>
> > But I really dont know how to inspect a file like real.h 
> > (real_value)/real.c?
>
> Use cc1 to build a test program with selected floating-point constants in
> it.  Set breakpoints on appropriate functions in real.c (e.g. related to
> converting strings for real constants into the internal representation).
> Look at the representation produced for those constants to determine the
> particular conventions being used.
>
> --
> Joseph S. Myers
> jos...@codesourcery.com

Re: About GSOC.

[Tejas Joshi]

Hello.
Representations of real numbers in real.c are a little complex to
understand right now for me. I am still trying to understand them and
figure them out using gdb and cscope. Though conventions are given in
comments in real.c, I will still be trying to figure it out. The
equation and its bitwise representation is not pretty elaborated in
any documentation I could find.

x = s * b^e * \sum_{k=1}^p f_k * b^{-k}

where
s = sign (+- 1)
b = base or radix, here always 2
e = exponent
p = precision (the number of base-b digits in the significand)
f_k = the digits of the significand.

In mean time, I've tried real_round function to work like roundeven. I
will try to submit a clean patch along with roundeven implemented
separately with changes like in builtins.def, adding cases, etc.

void
real_round (REAL_VALUE_TYPE *r, format_helper fmt,
const REAL_VALUE_TYPE *x)
{
#if 0
  do_add (r, x, &dconsthalf, x->sign);
  do_fix_trunc (r, r);
  if (fmt)
real_convert (r, fmt, r);
#endif
  fprintf (stderr, "\nhere\n");
  real_value z;
  do_fix_trunc (&z, x);
  HOST_WIDE_INT i = real_to_integer (&z);
  fprintf (stderr, "\n i = %ld\n", i);
  if (i % 2)
do_add (r, &z, &dconstm1, 0);
  else
*r = z;
}

Thanks.
-Tejas

On Sat, 26 Jan 2019 at 03:02, Joseph Myers  wrote:
>
> On Sat, 26 Jan 2019, Tejas Joshi wrote:
>
> > function with byte-byte comparison which also include mpfr. (Correct
> > me if I am wrong.) What is the significance of mpfr related to these
> > internal representations?
>
> real.c provides a fixed-size representation of floating-point numbers that
> allows for various non-IEEE formats supported by GCC, and also allows
> functions from dfp.c to be used for decimal floating-point formats.
>
> MPFR is used in GCC to provide operations that are nontrivial to
> implement, especially those that are nontrivial to implement in such a
> fixed-size context.  real.c operations wrap around MPFR ones where
> appropriate, doing whatever's needed in cases where there are non-IEEE
> semantics or sets of values.
>
> --
> Joseph S. Myers
> jos...@codesourcery.com

Re: About GSOC.

[Tejas Joshi]

Hello.
I have implemented roundeven function in real.c as follows: (and
respective changes in real.h)

/* Round X to nearest even integer towards zero. */

void
real_roundeven (REAL_VALUE_TYPE *r, format_helper fmt,
const REAL_VALUE_TYPE *x)
{
  REAL_VALUE_TYPE t;

  do_fix_trunc (&t, x);
  HOST_WIDE_INT i = real_to_integer (&t);
  if(i % 2)
do_add (r, &t, &dconstm1, 0);
  else
*r = t;
}

Although I cant get it to test like

int foo()
{
double x = __builtin_roundeven (3.5);
printf("%f",x);
return (int) x;
}
Because I do not know its dependencies through other files. I tried to
track them down by inspecting real_ceil function, but it also includes
other optimization procedures like folding. How do I know enough
declarations to be made in respective files?

Thanks.
-Tejas

On Mon, 28 Jan 2019 at 22:33, Tejas Joshi  wrote:
>
> Hello.
> Representations of real numbers in real.c are a little complex to
> understand right now for me. I am still trying to understand them and
> figure them out using gdb and cscope. Though conventions are given in
> comments in real.c, I will still be trying to figure it out. The
> equation and its bitwise representation is not pretty elaborated in
> any documentation I could find.
>
> x = s * b^e * \sum_{k=1}^p f_k * b^{-k}
>
> where
> s = sign (+- 1)
> b = base or radix, here always 2
> e = exponent
> p = precision (the number of base-b digits in the significand)
> f_k = the digits of the significand.
>
> In mean time, I've tried real_round function to work like roundeven. I
> will try to submit a clean patch along with roundeven implemented
> separately with changes like in builtins.def, adding cases, etc.
>
> void
> real_round (REAL_VALUE_TYPE *r, format_helper fmt,
> const REAL_VALUE_TYPE *x)
> {
> #if 0
>   do_add (r, x, &dconsthalf, x->sign);
>   do_fix_trunc (r, r);
>   if (fmt)
> real_convert (r, fmt, r);
> #endif
>   fprintf (stderr, "\nhere\n");
>   real_value z;
>   do_fix_trunc (&z, x);
>   HOST_WIDE_INT i = real_to_integer (&z);
>   fprintf (stderr, "\n i = %ld\n", i);
>   if (i % 2)
> do_add (r, &z, &dconstm1, 0);
>   else
> *r = z;
> }
>
> Thanks.
> -Tejas
>
> On Sat, 26 Jan 2019 at 03:02, Joseph Myers  wrote:
> >
> > On Sat, 26 Jan 2019, Tejas Joshi wrote:
> >
> > > function with byte-byte comparison which also include mpfr. (Correct
> > > me if I am wrong.) What is the significance of mpfr related to these
> > > internal representations?
> >
> > real.c provides a fixed-size representation of floating-point numbers that
> > allows for various non-IEEE formats supported by GCC, and also allows
> > functions from dfp.c to be used for decimal floating-point formats.
> >
> > MPFR is used in GCC to provide operations that are nontrivial to
> > implement, especially those that are nontrivial to implement in such a
> > fixed-size context.  real.c operations wrap around MPFR ones where
> > appropriate, doing whatever's needed in cases where there are non-IEEE
> > semantics or sets of values.
> >
> > --
> > Joseph S. Myers
> > jos...@codesourcery.com

Re: About GSOC.

[Tejas Joshi]

Thanks.
> Did you add an entry for roundeven in builtins.def ?
Yes, I did.

Find here the attached patch.diff for which I did the changes to
implement roundeven. There might be some unnecessary changes and some
necessary changes which have not been made.

Regards,
-Tejas

On Mon, 4 Feb 2019 at 20:36, Prathamesh Kulkarni
 wrote:
>
> On Mon, 4 Feb 2019 at 20:10, Tejas Joshi  wrote:
> >
> > Hello.
> > I have implemented roundeven function in real.c as follows: (and
> > respective changes in real.h)
> It's a better idea to include all changes in patch instead of copy-pasting.
> Use the command:
> git diff > patch.diff
> which will create a file called "patch.diff" containing the changes
> and send it as an attachment.
> >
> > /* Round X to nearest even integer towards zero. */
> >
> > void
> > real_roundeven (REAL_VALUE_TYPE *r, format_helper fmt,
> > const REAL_VALUE_TYPE *x)
> > {
> >   REAL_VALUE_TYPE t;
> >
> >   do_fix_trunc (&t, x);
> >   HOST_WIDE_INT i = real_to_integer (&t);
> >   if(i % 2)
> > do_add (r, &t, &dconstm1, 0);
> >   else
> > *r = t;
> > }
> >
> > Although I cant get it to test like
> >
> > int foo()
> > {
> > double x = __builtin_roundeven (3.5);
> > printf("%f",x);
> > return (int) x;
> > }
> > Because I do not know its dependencies through other files. I tried to
> > track them down by inspecting real_ceil function, but it also includes
> > other optimization procedures like folding. How do I know enough
> > declarations to be made in respective files?
> Did you add an entry for roundeven in builtins.def ?
>
> Thanks,
> Prathamesh
> >
> > Thanks.
> > -Tejas
> >
> > On Mon, 28 Jan 2019 at 22:33, Tejas Joshi  wrote:
> > >
> > > Hello.
> > > Representations of real numbers in real.c are a little complex to
> > > understand right now for me. I am still trying to understand them and
> > > figure them out using gdb and cscope. Though conventions are given in
> > > comments in real.c, I will still be trying to figure it out. The
> > > equation and its bitwise representation is not pretty elaborated in
> > > any documentation I could find.
> > >
> > > x = s * b^e * \sum_{k=1}^p f_k * b^{-k}
> > >
> > > where
> > > s = sign (+- 1)
> > > b = base or radix, here always 2
> > > e = exponent
> > > p = precision (the number of base-b digits in the significand)
> > > f_k = the digits of the significand.
> > >
> > > In mean time, I've tried real_round function to work like roundeven. I
> > > will try to submit a clean patch along with roundeven implemented
> > > separately with changes like in builtins.def, adding cases, etc.
> > >
> > > void
> > > real_round (REAL_VALUE_TYPE *r, format_helper fmt,
> > > const REAL_VALUE_TYPE *x)
> > > {
> > > #if 0
> > >   do_add (r, x, &dconsthalf, x->sign);
> > >   do_fix_trunc (r, r);
> > >   if (fmt)
> > > real_convert (r, fmt, r);
> > > #endif
> > >   fprintf (stderr, "\nhere\n");
> > >   real_value z;
> > >   do_fix_trunc (&z, x);
> > >   HOST_WIDE_INT i = real_to_integer (&z);
> > >   fprintf (stderr, "\n i = %ld\n", i);
> > >   if (i % 2)
> > > do_add (r, &z, &dconstm1, 0);
> > >   else
> > > *r = z;
> > > }
> > >
> > > Thanks.
> > > -Tejas
> > >
> > > On Sat, 26 Jan 2019 at 03:02, Joseph Myers  
> > > wrote:
> > > >
> > > > On Sat, 26 Jan 2019, Tejas Joshi wrote:
> > > >
> > > > > function with byte-byte comparison which also include mpfr. (Correct
> > > > > me if I am wrong.) What is the significance of mpfr related to these
> > > > > internal representations?
> > > >
> > > > real.c provides a fixed-size representation of floating-point numbers 
> > > > that
> > > > allows for various non-IEEE formats supported by GCC, and also allows
> > > > functions from dfp.c to be used for decimal floating-point formats.
> > > >
> > > > MPFR is used in GCC to provide operations that are nontrivial to
> > > > implement, especially those that are nontrivial to implement in such a
> > > > fixed-size context. 

Re: About GSOC.

[Tejas Joshi]

Hi.
Although now, I am unable to build the compiler.
The build exited returning status as:

DEF_INTERNAL_FLT_FN (ROUNDEVEN) has no associated built-in functions

I have added the entry in fold_const_call_ss() and do not find any
other place to add the case.
Here is the latest patch.

On Mon, 4 Feb 2019 at 22:14, Prathamesh Kulkarni
 wrote:
>
> On Mon, 4 Feb 2019 at 21:27, Tejas Joshi  wrote:
> >
> > Thanks.
> > > Did you add an entry for roundeven in builtins.def ?
> > Yes, I did.
> >
> > Find here the attached patch.diff for which I did the changes to
> > implement roundeven. There might be some unnecessary changes and some
> > necessary changes which have not been made.
> You haven't called roundeven() in the patch. You'll need to add an
> entry in fold_const_call_ss()
> similar to real_ceil, and probably in other places too.
>
> Thanks,
> Prathamesh
> >
> > Regards,
> > -Tejas
> >
> > On Mon, 4 Feb 2019 at 20:36, Prathamesh Kulkarni
> >  wrote:
> > >
> > > On Mon, 4 Feb 2019 at 20:10, Tejas Joshi  wrote:
> > > >
> > > > Hello.
> > > > I have implemented roundeven function in real.c as follows: (and
> > > > respective changes in real.h)
> > > It's a better idea to include all changes in patch instead of 
> > > copy-pasting.
> > > Use the command:
> > > git diff > patch.diff
> > > which will create a file called "patch.diff" containing the changes
> > > and send it as an attachment.
> > > >
> > > > /* Round X to nearest even integer towards zero. */
> > > >
> > > > void
> > > > real_roundeven (REAL_VALUE_TYPE *r, format_helper fmt,
> > > > const REAL_VALUE_TYPE *x)
> > > > {
> > > >   REAL_VALUE_TYPE t;
> > > >
> > > >   do_fix_trunc (&t, x);
> > > >   HOST_WIDE_INT i = real_to_integer (&t);
> > > >   if(i % 2)
> > > > do_add (r, &t, &dconstm1, 0);
> > > >   else
> > > > *r = t;
> > > > }
> > > >
> > > > Although I cant get it to test like
> > > >
> > > > int foo()
> > > > {
> > > > double x = __builtin_roundeven (3.5);
> > > > printf("%f",x);
> > > > return (int) x;
> > > > }
> > > > Because I do not know its dependencies through other files. I tried to
> > > > track them down by inspecting real_ceil function, but it also includes
> > > > other optimization procedures like folding. How do I know enough
> > > > declarations to be made in respective files?
> > > Did you add an entry for roundeven in builtins.def ?
> > >
> > > Thanks,
> > > Prathamesh
> > > >
> > > > Thanks.
> > > > -Tejas
> > > >
> > > > On Mon, 28 Jan 2019 at 22:33, Tejas Joshi  
> > > > wrote:
> > > > >
> > > > > Hello.
> > > > > Representations of real numbers in real.c are a little complex to
> > > > > understand right now for me. I am still trying to understand them and
> > > > > figure them out using gdb and cscope. Though conventions are given in
> > > > > comments in real.c, I will still be trying to figure it out. The
> > > > > equation and its bitwise representation is not pretty elaborated in
> > > > > any documentation I could find.
> > > > >
> > > > > x = s * b^e * \sum_{k=1}^p f_k * b^{-k}
> > > > >
> > > > > where
> > > > > s = sign (+- 1)
> > > > > b = base or radix, here always 2
> > > > > e = exponent
> > > > > p = precision (the number of base-b digits in the significand)
> > > > > f_k = the digits of the significand.
> > > > >
> > > > > In mean time, I've tried real_round function to work like roundeven. I
> > > > > will try to submit a clean patch along with roundeven implemented
> > > > > separately with changes like in builtins.def, adding cases, etc.
> > > > >
> > > > > void
> > > > > real_round (REAL_VALUE_TYPE *r, format_helper fmt,
> > > > > const REAL_VALUE_TYPE *x)
> > > > > {
> > > > > #if 0
> > > > >   do_add (r, x, &dconsthalf, x->sign);
> > > > >   do_fix_trunc

Re: About GSOC.

[Tejas Joshi]

Hello.
I had a little pause on roundeven due to seminars in my college. I've
tried to implement roundeven but can not figure out what are just
minimal needs to roundeven be called for a test program like
__builtin_roundeven();
Also, build exited returning status as:

DEF_INTERNAL_FLT_FN (ROUNDEVEN) has no associated built-in functions

Here is the .diff flie.

Thanks,
-Tejas

On Mon, 4 Feb 2019 at 22:55, Tejas Joshi  wrote:
>
> Hi.
> Although now, I am unable to build the compiler.
> The build exited returning status as:
>
> DEF_INTERNAL_FLT_FN (ROUNDEVEN) has no associated built-in functions
>
> I have added the entry in fold_const_call_ss() and do not find any
> other place to add the case.
> Here is the latest patch.
>
> On Mon, 4 Feb 2019 at 22:14, Prathamesh Kulkarni
>  wrote:
> >
> > On Mon, 4 Feb 2019 at 21:27, Tejas Joshi  wrote:
> > >
> > > Thanks.
> > > > Did you add an entry for roundeven in builtins.def ?
> > > Yes, I did.
> > >
> > > Find here the attached patch.diff for which I did the changes to
> > > implement roundeven. There might be some unnecessary changes and some
> > > necessary changes which have not been made.
> > You haven't called roundeven() in the patch. You'll need to add an
> > entry in fold_const_call_ss()
> > similar to real_ceil, and probably in other places too.
> >
> > Thanks,
> > Prathamesh
> > >
> > > Regards,
> > > -Tejas
> > >
> > > On Mon, 4 Feb 2019 at 20:36, Prathamesh Kulkarni
> > >  wrote:
> > > >
> > > > On Mon, 4 Feb 2019 at 20:10, Tejas Joshi  
> > > > wrote:
> > > > >
> > > > > Hello.
> > > > > I have implemented roundeven function in real.c as follows: (and
> > > > > respective changes in real.h)
> > > > It's a better idea to include all changes in patch instead of 
> > > > copy-pasting.
> > > > Use the command:
> > > > git diff > patch.diff
> > > > which will create a file called "patch.diff" containing the changes
> > > > and send it as an attachment.
> > > > >
> > > > > /* Round X to nearest even integer towards zero. */
> > > > >
> > > > > void
> > > > > real_roundeven (REAL_VALUE_TYPE *r, format_helper fmt,
> > > > > const REAL_VALUE_TYPE *x)
> > > > > {
> > > > >   REAL_VALUE_TYPE t;
> > > > >
> > > > >   do_fix_trunc (&t, x);
> > > > >   HOST_WIDE_INT i = real_to_integer (&t);
> > > > >   if(i % 2)
> > > > > do_add (r, &t, &dconstm1, 0);
> > > > >   else
> > > > > *r = t;
> > > > > }
> > > > >
> > > > > Although I cant get it to test like
> > > > >
> > > > > int foo()
> > > > > {
> > > > > double x = __builtin_roundeven (3.5);
> > > > > printf("%f",x);
> > > > > return (int) x;
> > > > > }
> > > > > Because I do not know its dependencies through other files. I tried to
> > > > > track them down by inspecting real_ceil function, but it also includes
> > > > > other optimization procedures like folding. How do I know enough
> > > > > declarations to be made in respective files?
> > > > Did you add an entry for roundeven in builtins.def ?
> > > >
> > > > Thanks,
> > > > Prathamesh
> > > > >
> > > > > Thanks.
> > > > > -Tejas
> > > > >
> > > > > On Mon, 28 Jan 2019 at 22:33, Tejas Joshi  
> > > > > wrote:
> > > > > >
> > > > > > Hello.
> > > > > > Representations of real numbers in real.c are a little complex to
> > > > > > understand right now for me. I am still trying to understand them 
> > > > > > and
> > > > > > figure them out using gdb and cscope. Though conventions are given 
> > > > > > in
> > > > > > comments in real.c, I will still be trying to figure it out. The
> > > > > > equation and its bitwise representation is not pretty elaborated in
> > > > > > any documentation I could find.
> > > > > >
> > > > > > x = s * b^e * \sum_{k=1}^p f_k * b^{-k}
> > > > > >
> > > > &

Re: About GSOC.

[Tejas Joshi]

Hello.
I have developed a fairly working patch for roundeven, attaching herewith.
The testcase function as follows :

double f()
{
  double x = 4.5;
  double ret = __builtin_roundeven (x);
  return ret;
}

We can inspect the file foo.c.028t.ccp1, where we can see f() returns
value 4.0e+0.
I am also writing the proposal and make draft ready in couple of days
for community review.
Do roundeven have to be added in internals-fn.def to be called internal?

Thanks,
-Tejas


On Sun, 24 Feb 2019 at 17:39, Tejas Joshi  wrote:
>
> Hello.
> I had a little pause on roundeven due to seminars in my college. I've
> tried to implement roundeven but can not figure out what are just
> minimal needs to roundeven be called for a test program like
> __builtin_roundeven();
> Also, build exited returning status as:
>
> DEF_INTERNAL_FLT_FN (ROUNDEVEN) has no associated built-in functions
>
> Here is the .diff flie.
>
> Thanks,
> -Tejas
>
> On Mon, 4 Feb 2019 at 22:55, Tejas Joshi  wrote:
> >
> > Hi.
> > Although now, I am unable to build the compiler.
> > The build exited returning status as:
> >
> > DEF_INTERNAL_FLT_FN (ROUNDEVEN) has no associated built-in functions
> >
> > I have added the entry in fold_const_call_ss() and do not find any
> > other place to add the case.
> > Here is the latest patch.
> >
> > On Mon, 4 Feb 2019 at 22:14, Prathamesh Kulkarni
> >  wrote:
> > >
> > > On Mon, 4 Feb 2019 at 21:27, Tejas Joshi  wrote:
> > > >
> > > > Thanks.
> > > > > Did you add an entry for roundeven in builtins.def ?
> > > > Yes, I did.
> > > >
> > > > Find here the attached patch.diff for which I did the changes to
> > > > implement roundeven. There might be some unnecessary changes and some
> > > > necessary changes which have not been made.
> > > You haven't called roundeven() in the patch. You'll need to add an
> > > entry in fold_const_call_ss()
> > > similar to real_ceil, and probably in other places too.
> > >
> > > Thanks,
> > > Prathamesh
> > > >
> > > > Regards,
> > > > -Tejas
> > > >
> > > > On Mon, 4 Feb 2019 at 20:36, Prathamesh Kulkarni
> > > >  wrote:
> > > > >
> > > > > On Mon, 4 Feb 2019 at 20:10, Tejas Joshi  
> > > > > wrote:
> > > > > >
> > > > > > Hello.
> > > > > > I have implemented roundeven function in real.c as follows: (and
> > > > > > respective changes in real.h)
> > > > > It's a better idea to include all changes in patch instead of 
> > > > > copy-pasting.
> > > > > Use the command:
> > > > > git diff > patch.diff
> > > > > which will create a file called "patch.diff" containing the changes
> > > > > and send it as an attachment.
> > > > > >
> > > > > > /* Round X to nearest even integer towards zero. */
> > > > > >
> > > > > > void
> > > > > > real_roundeven (REAL_VALUE_TYPE *r, format_helper fmt,
> > > > > > const REAL_VALUE_TYPE *x)
> > > > > > {
> > > > > >   REAL_VALUE_TYPE t;
> > > > > >
> > > > > >   do_fix_trunc (&t, x);
> > > > > >   HOST_WIDE_INT i = real_to_integer (&t);
> > > > > >   if(i % 2)
> > > > > > do_add (r, &t, &dconstm1, 0);
> > > > > >   else
> > > > > > *r = t;
> > > > > > }
> > > > > >
> > > > > > Although I cant get it to test like
> > > > > >
> > > > > > int foo()
> > > > > > {
> > > > > > double x = __builtin_roundeven (3.5);
> > > > > > printf("%f",x);
> > > > > > return (int) x;
> > > > > > }
> > > > > > Because I do not know its dependencies through other files. I tried 
> > > > > > to
> > > > > > track them down by inspecting real_ceil function, but it also 
> > > > > > includes
> > > > > > other optimization procedures like folding. How do I know enough
> > > > > > declarations to be made in respective files?
> > > > > Did you add an entry for roundeven in builtins.def ?
> > > > >
> > > > > Thanks,
> > > > 

Re: About GSOC.

[Tejas Joshi]

Hello.
Here is the proposal draft for the idea. Please review and suggest
changes or modifications.

https://docs.google.com/document/d/15DEXa5NZL6Q_X_zlME3NNJw2zVimFWzi16x7cgIDqL0/edit?usp=sharing

Thanks,
-Tejas

On Tue, 2 Apr 2019 at 01:23, Joseph Myers  wrote:
>
> On Sat, 30 Mar 2019, Tejas Joshi wrote:
>
> > Hello.
> > I have developed a fairly working patch for roundeven, attaching herewith.
> > The testcase function as follows :
> >
> > double f()
> > {
> >   double x = 4.5;
> >   double ret = __builtin_roundeven (x);
> >   return ret;
> > }
>
> Tests need to be added to the testsuite, covering a range of inputs and
> automatically verifying that the test is optimized correctly.
>
> "Round X to nearest even integer towards zero." is not correct.  The
> roundeven function does not round to an even integer.  It rounds to the
> nearest integer, whether even or odd - but, if two integers are equally
> close, the result is even (and for any input that is not halfway between
> two integers, it produces the same result as round (which rounds halfway
> cases away from zero) - so 2.501, 3 and 3.499 round to 3, but 2.5 rounds
> to 2 not 3, unlike round, and 3.5 rounds to 4, as with round).
>
> The function can't rely on arguments being in the range of HOST_WIDE_INT,
> so it needs to examine the REAL_VALUE_TYPE representation directly to
> determine whether it's half way between two integers and which way to
> round in that case.
>
> --
> Joseph S. Myers
> jos...@codesourcery.com

Re: About GSOC.

[Tejas Joshi]

Hello.
Taking the notes from Joseph under consideration, I have developed a
fairly working patch for roundeven, attached herewith.
I have done bit-wise calculations to check for halfway cases, though
HOST_WIDE_INT is only used to check for even and odd numbers (or is it
necessary to do bit-wise for this too?). Also, why unsigned long
sig[SIGSZ] in real_value has to be an array? (for 64 bit system, its
an array of size 3, mostly first 2 values being 0?).
Thanks.

Regards,
-Tejas
diff --git a/gcc/builtins.c b/gcc/builtins.c
index 25e01e4092b..0b2d6bf82f9 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -2067,6 +2067,7 @@ mathfn_built_in_2 (tree type, combined_fn fn)
 CASE_MATHFN (REMQUO)
 CASE_MATHFN_FLOATN (RINT)
 CASE_MATHFN_FLOATN (ROUND)
+CASE_MATHFN (ROUNDEVEN)
 CASE_MATHFN (SCALB)
 CASE_MATHFN (SCALBLN)
 CASE_MATHFN (SCALBN)
diff --git a/gcc/builtins.def b/gcc/builtins.def
index ef89729fd0c..e1d593a8765 100644
--- a/gcc/builtins.def
+++ b/gcc/builtins.def
@@ -542,6 +542,9 @@ DEF_C99_BUILTIN(BUILT_IN_RINTL, "rintl", BT_FN_LONGDOUBLE_LONGDOUBLE, AT
 #define RINT_TYPE(F) BT_FN_##F##_##F
 DEF_EXT_LIB_FLOATN_NX_BUILTINS (BUILT_IN_RINT, "rint", RINT_TYPE, ATTR_CONST_NOTHROW_LEAF_LIST)
 #undef RINT_TYPE
+DEF_EXT_LIB_BUILTIN(BUILT_IN_ROUNDEVEN, "roundeven", BT_FN_DOUBLE_DOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
+DEF_EXT_LIB_BUILTIN(BUILT_IN_ROUNDEVENF, "roundevenf", BT_FN_FLOAT_FLOAT, ATTR_CONST_NOTHROW_LEAF_LIST)
+DEF_EXT_LIB_BUILTIN(BUILT_IN_ROUNDEVENL, "roundevenl", BT_FN_LONGDOUBLE_LONGDOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_C99_BUILTIN(BUILT_IN_ROUND, "round", BT_FN_DOUBLE_DOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_C99_BUILTIN(BUILT_IN_ROUNDF, "roundf", BT_FN_FLOAT_FLOAT, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_C99_BUILTIN(BUILT_IN_ROUNDL, "roundl", BT_FN_LONGDOUBLE_LONGDOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
diff --git a/gcc/fold-const-call.c b/gcc/fold-const-call.c
index 06a420601c0..7eafd91e9a2 100644
--- a/gcc/fold-const-call.c
+++ b/gcc/fold-const-call.c
@@ -792,6 +792,14 @@ fold_const_call_ss (real_value *result, combined_fn fn,
 	}
   return false;
 
+case CFN_BUILT_IN_ROUNDEVEN:
+  if (!REAL_VALUE_ISNAN (*arg) || !flag_errno_math)
+  {
+real_roundeven (result, format, arg);
+return true;
+  }
+  return false;
+
 CASE_CFN_LOGB:
   return fold_const_logb (result, arg, format);
 
@@ -854,6 +862,9 @@ fold_const_call_ss (wide_int *result, combined_fn fn,
   return fold_const_conversion (result, real_round, arg,
 precision, format);
 
+case CFN_BUILT_IN_ROUNDEVEN:
+  return fold_const_conversion (result, real_roundeven, arg, precision, format);
+
 CASE_CFN_IRINT:
 CASE_CFN_LRINT:
 CASE_CFN_LLRINT:
diff --git a/gcc/fold-const.c b/gcc/fold-const.c
index 59cedeafd71..30c409e95bf 100644
--- a/gcc/fold-const.c
+++ b/gcc/fold-const.c
@@ -329,6 +329,7 @@ negate_mathfn_p (combined_fn fn)
 CASE_CFN_LLROUND:
 CASE_CFN_LROUND:
 CASE_CFN_ROUND:
+CASE_CFN_ROUNDEVEN:
 CASE_CFN_SIN:
 CASE_CFN_SINH:
 CASE_CFN_TAN:
@@ -13060,6 +13061,8 @@ tree_call_nonnegative_warnv_p (tree type, combined_fn fn, tree arg0, tree arg1,
 CASE_CFN_RINT_FN:
 CASE_CFN_ROUND:
 CASE_CFN_ROUND_FN:
+CASE_CFN_ROUNDEVEN:
+CASE_CFN_ROUNDEVEN_FN:
 CASE_CFN_SCALB:
 CASE_CFN_SCALBLN:
 CASE_CFN_SCALBN:
@@ -13583,6 +13586,8 @@ integer_valued_real_call_p (combined_fn fn, tree arg0, tree arg1, int depth)
 CASE_CFN_RINT_FN:
 CASE_CFN_ROUND:
 CASE_CFN_ROUND_FN:
+CASE_CFN_ROUNDEVEN:
+CASE_CFN_ROUNDEVEN_FN:
 CASE_CFN_TRUNC:
 CASE_CFN_TRUNC_FN:
   return true;
diff --git a/gcc/real.c b/gcc/real.c
index f822ae82d61..533d471a89b 100644
--- a/gcc/real.c
+++ b/gcc/real.c
@@ -5010,6 +5010,43 @@ real_round (REAL_VALUE_TYPE *r, format_helper fmt,
 real_convert (r, fmt, r);
 }
 
+bool
+is_halfway_below (const REAL_VALUE_TYPE *r)
+{
+  unsigned long tempsig[SIGSZ];
+  unsigned int n = SIGNIFICAND_BITS - REAL_EXP (r);
+  int i, w = n / HOST_BITS_PER_LONG;
+
+  for (i = 0; i < SIGSZ; ++i)
+tempsig[i] = r->sig[i];
+
+  for (i = 0; i < w; ++i)
+tempsig[i] = 0;
+
+  tempsig[w] &= (((unsigned long)1 << ((n % HOST_BITS_PER_LONG) - 1)) - 1);
+  
+  if (tempsig[w] == 0)
+return true;
+  return false;
+}
+
+/* Round X to nearest integer, rounding halfway cases towards even. */
+
+void
+real_roundeven (REAL_VALUE_TYPE *r, format_helper fmt,
+		const REAL_VALUE_TYPE *x)
+{
+  if (is_halfway_below (x))
+  {
+do_add (r, x, &dconsthalf, x->sign);
+HOST_WIDE_INT i = real_to_integer (r);
+if (i % 2)
+  do_add (r, r, &dconstm1, x->sign);
+  }
+  else
+real_round (r, fmt, x);
+}
+
 /* Set the sign of R to the sign of X.  */
 
 void
diff --git a/gcc/real.h b/gcc/real.h
index 0ce42565708..10898eae79e 100644
--- a/gcc/real.h
+++ b/gcc/real.h
@@ -499,6 +499,8 @@ extern void real_ceil (REAL_VALUE_TYPE *, format_helper,
 		   const REAL

Re: About GSOC.

[Tejas Joshi]

Hello.
Thanks for your inputs.

If it is meant to be testing whether a value is halfway between two
integers, there are two things you need to test.  You need to test whether
the bit with value 0.5 is 0 or 1 (which this function doesn't seem to
test) - and you also need to test whether *all* bits below it are zero or
not (this function only appears to check bits in a single word,
disregarding all the lower words, which is not correct).

Hello.
As per my understanding, 3.5 would be represented in GCC as follows :
r->uexp  = 2
and
r->sig[2] = 11100 in binary 64 bit. (first 2 bits being 3 and
following 10000 being 0.5, which later only happens for halfway cases)
So, if we clear out the significand part and the immediate bit to the right
which represent 0.5, the entire significand would become 0 due to bit-wise
ANDing.

> +  tempsig[w] &= (((unsigned long)1 << ((n % HOST_BITS_PER_LONG) - 1)) -
> 1);
>

That is what the following line intend to do. The clearing part would
change the significand, that's why significand was copied to a temporary
array for checking. This logic is inspired by the clear_significand_below
function. Or isn't this the way it was meant to be implemented? Also, why
unsigned long sig[SIGSZ] has to be an array?

If n % HOST_BITS_PER_LONG is 0, this code would shift by -1, which isn't
>

Yes, the condition checking is necessary here. I will incorporate the
changes and find a way to check if the number is even or odd bit-wise and
add test cases in the test suite as soon as possible.
Thanks.

Regards,
-Tejas

On Tue, 7 May 2019 at 22:47, Joseph Myers  wrote:

> On Sat, 4 May 2019, Tejas Joshi wrote:
>
> > Hello.
> > Taking the notes from Joseph under consideration, I have developed a
> > fairly working patch for roundeven, attached herewith.
>
> There are several issues here.  One key one is that you haven't added any
> testcases to the GCC testsuite.  I'd expect tests added that test lots of
> different inputs, for all the float, double and long double types, to
> verify the results are as expected.  That would include various exactly
> halfway cases - but also cases that are halfway plus or minus 1ulp.  Tests
> would be appropriately conditional on the floating-point formats as needed
> - testing for IEEE binary128 long double, on configurations that have that
> type, would help cover certain cases, such as where the integer part
> exceeds 2^64 but there is still a fractional part.
>
> Given tests and confirmation that they have passed in various
> configurations, it's a lot easier to have confidence in the code - and if
> possible issues are spotted in the code, they may point the way to missing
> tests.  That is, tests are a key piece of a patch that makes it much
> easier to review the patch.
>
> > I have done bit-wise calculations to check for halfway cases, though
> > HOST_WIDE_INT is only used to check for even and odd numbers (or is it
> > necessary to do bit-wise for this too?). Also, why unsigned long
>
> Yes, you need to use bit-wise checks for odd and even numbers, because you
> can have a nonzero fractional part with an integer part that is too big to
> be represented in HOST_WIDE_INT.  With IEEE binary128, you can have 112
> bits in the integer part and still have 0.5 as the fractional part.
>
> > diff --git a/gcc/real.c b/gcc/real.c
> > index f822ae82d61..533d471a89b 100644
> > --- a/gcc/real.c
> > +++ b/gcc/real.c
> > @@ -5010,6 +5010,43 @@ real_round (REAL_VALUE_TYPE *r, format_helper fmt,
> >  real_convert (r, fmt, r);
> >  }
> >
> > +bool
> > +is_halfway_below (const REAL_VALUE_TYPE *r)
> > +{
> > +  unsigned long tempsig[SIGSZ];
> > +  unsigned int n = SIGNIFICAND_BITS - REAL_EXP (r);
> > +  int i, w = n / HOST_BITS_PER_LONG;
> > +
> > +  for (i = 0; i < SIGSZ; ++i)
> > +tempsig[i] = r->sig[i];
> > +
> > +  for (i = 0; i < w; ++i)
> > +tempsig[i] = 0;
> > +
> > +  tempsig[w] &= (((unsigned long)1 << ((n % HOST_BITS_PER_LONG) - 1)) -
> 1);
> > +
> > +  if (tempsig[w] == 0)
> > +return true;
>
> > +  return false;
>
> The logic in this function does not make sense to me.
>
> First, it needs a comment above the function defining its exact
> semantics.
> Since it lacks a comment, I have to guess based on the name.
>
> If it is meant to be testing whether a value is halfway between two
> integers, there are two things you need to test.  You need to test whether
> the bit with value 0.5 is 0 or 1 (which this function doesn't seem to
> test) - and you also need to test whether *all* bits below it are zero or
> not (this function only appears to check bits in 

Re: About GSOC.

[Tejas Joshi]

I should have taken all the test cases into consideration. Fool of me. I
will try to make changes taking all the test cases into consideration along
with the testsuite.
Thanks.

On Wed, 8 May 2019 at 02:31, Joseph Myers  wrote:

> On Wed, 8 May 2019, Tejas Joshi wrote:
>
> > Hello.
> > As per my understanding, 3.5 would be represented in GCC as follows :
> > r->uexp  = 2
> > and
> > r->sig[2] = 11100 in binary 64 bit. (first 2 bits being 3 and
> > following 10000 being 0.5, which later only happens for halfway
> cases)
> > So, if we clear out the significand part and the immediate bit to the
> right
> > which represent 0.5, the entire significand would become 0 due to
> bit-wise
> > ANDing.
> >
> > > +  tempsig[w] &= (((unsigned long)1 << ((n % HOST_BITS_PER_LONG) - 1))
> -
> > > 1);
> > >
> >
> > That is what the following line intend to do. The clearing part would
> > change the significand, that's why significand was copied to a temporary
>
> That much is fine.  My issues are two other things:
>
> * The function would wrongly return true for 3, not just for 3.5, because
> it never checks the bit representing 0.5.  (If you don't care what it
> returns for 3, see my previous point about every function needing a
> comment defining its semantics.  Without such a comment, I have to guess,
> and my guess here is that the function should return true for 3.5 but
> false for 3 and for 3.5000...0001.)
>
> * The function would wrongly return true for 3.5000...0001, if there are
> enough 0s that all those low bits in sig[2] are 0, but some low bits in
> sig[1] or sig[0] are not 0.
>
> And also:
>
> * You should never need to modify parts of (a copy of) the significand in
> place.  Compare low parts of the significand (masked as needed) with 0.
> If not 0, just return false.  Likewise for comparing the 0.5 bit with 1.
> It's not that copying and modifying in place results in incorrect logic,
> it's simply excessively convoluted compared to things like:
>
>   if ((something & mask) != 0)
> return false
>
> (the function is probably twice as long as necessary because of that
> copying).
>
> > array for checking. This logic is inspired by the clear_significand_below
> > function. Or isn't this the way it was meant to be implemented? Also, why
> > unsigned long sig[SIGSZ] has to be an array?
>
> What would it be other than an array?  It can't be a single scalar because
> floating-point significands may be longer than any supported integer type
> on the host (remember the IEEE binary128 case).  And if you made it a
> sequence of individually named fields, a load of loops would need to be
> manually unrolled, which would be much more error prone and hard to read.
>
> --
> Joseph S. Myers
> jos...@codesourcery.com
>

Re: About GSOC.

[Tejas Joshi]

Hello.
I can't figure out from the documentation how to add test cases in the
testsuite and inspect the results. How can I do that? Although, Taking
the mentioned conditions under consideration, I have made another
patch, attached.

Thanks,
-Tejas


On Wed, 8 May 2019 at 09:01, Tejas Joshi  wrote:
>
> I should have taken all the test cases into consideration. Fool of me. I will 
> try to make changes taking all the test cases into consideration along with 
> the testsuite.
> Thanks.
>
> On Wed, 8 May 2019 at 02:31, Joseph Myers  wrote:
>>
>> On Wed, 8 May 2019, Tejas Joshi wrote:
>>
>> > Hello.
>> > As per my understanding, 3.5 would be represented in GCC as follows :
>> > r->uexp  = 2
>> > and
>> > r->sig[2] = 11100 in binary 64 bit. (first 2 bits being 3 and
>> > following 10000 being 0.5, which later only happens for halfway cases)
>> > So, if we clear out the significand part and the immediate bit to the right
>> > which represent 0.5, the entire significand would become 0 due to bit-wise
>> > ANDing.
>> >
>> > > +  tempsig[w] &= (((unsigned long)1 << ((n % HOST_BITS_PER_LONG) - 1)) -
>> > > 1);
>> > >
>> >
>> > That is what the following line intend to do. The clearing part would
>> > change the significand, that's why significand was copied to a temporary
>>
>> That much is fine.  My issues are two other things:
>>
>> * The function would wrongly return true for 3, not just for 3.5, because
>> it never checks the bit representing 0.5.  (If you don't care what it
>> returns for 3, see my previous point about every function needing a
>> comment defining its semantics.  Without such a comment, I have to guess,
>> and my guess here is that the function should return true for 3.5 but
>> false for 3 and for 3.5000...0001.)
>>
>> * The function would wrongly return true for 3.5000...0001, if there are
>> enough 0s that all those low bits in sig[2] are 0, but some low bits in
>> sig[1] or sig[0] are not 0.
>>
>> And also:
>>
>> * You should never need to modify parts of (a copy of) the significand in
>> place.  Compare low parts of the significand (masked as needed) with 0.
>> If not 0, just return false.  Likewise for comparing the 0.5 bit with 1.
>> It's not that copying and modifying in place results in incorrect logic,
>> it's simply excessively convoluted compared to things like:
>>
>>   if ((something & mask) != 0)
>> return false
>>
>> (the function is probably twice as long as necessary because of that
>> copying).
>>
>> > array for checking. This logic is inspired by the clear_significand_below
>> > function. Or isn't this the way it was meant to be implemented? Also, why
>> > unsigned long sig[SIGSZ] has to be an array?
>>
>> What would it be other than an array?  It can't be a single scalar because
>> floating-point significands may be longer than any supported integer type
>> on the host (remember the IEEE binary128 case).  And if you made it a
>> sequence of individually named fields, a load of loops would need to be
>> manually unrolled, which would be much more error prone and hard to read.
>>
>> --
>> Joseph S. Myers
>> jos...@codesourcery.com
diff --git a/gcc/builtins.c b/gcc/builtins.c
index 25e01e4092b..0b2d6bf82f9 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -2067,6 +2067,7 @@ mathfn_built_in_2 (tree type, combined_fn fn)
 CASE_MATHFN (REMQUO)
 CASE_MATHFN_FLOATN (RINT)
 CASE_MATHFN_FLOATN (ROUND)
+CASE_MATHFN (ROUNDEVEN)
 CASE_MATHFN (SCALB)
 CASE_MATHFN (SCALBLN)
 CASE_MATHFN (SCALBN)
diff --git a/gcc/builtins.def b/gcc/builtins.def
index ef89729fd0c..e1d593a8765 100644
--- a/gcc/builtins.def
+++ b/gcc/builtins.def
@@ -542,6 +542,9 @@ DEF_C99_BUILTIN(BUILT_IN_RINTL, "rintl", BT_FN_LONGDOUBLE_LONGDOUBLE, AT
 #define RINT_TYPE(F) BT_FN_##F##_##F
 DEF_EXT_LIB_FLOATN_NX_BUILTINS (BUILT_IN_RINT, "rint", RINT_TYPE, ATTR_CONST_NOTHROW_LEAF_LIST)
 #undef RINT_TYPE
+DEF_EXT_LIB_BUILTIN(BUILT_IN_ROUNDEVEN, "roundeven", BT_FN_DOUBLE_DOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
+DEF_EXT_LIB_BUILTIN(BUILT_IN_ROUNDEVENF, "roundevenf", BT_FN_FLOAT_FLOAT, ATTR_CONST_NOTHROW_LEAF_LIST)
+DEF_EXT_LIB_BUILTIN(BUILT_IN_ROUNDEVENL, "roundevenl", BT_FN_LONGDOUBLE_LONGDOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_C99_BUILTIN(BUILT_IN_ROUND, "round", BT_FN_DOUBLE_DOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_C99_BUILTIN(BUILT_IN_ROUNDF, "roundf", BT_FN_FLOAT_FLOAT, ATTR_CO

Re: About GSOC.

[Tejas Joshi]

Hello.
I have added a test case in the testsuite referring to an existing one
as "builtin-rounding-1.c" in the /testsuite/gcc.dg/torture directory.
As follows :

/* { dg-do link } */

extern int link_error (int);

#define TEST(FN, VALUE, RESULT) \
  if (__builtin_##FN (VALUE) != RESULT) link_error (__LINE__);

int
main (void)
{
  TEST(roundeven,  0, 0);
  TEST(roundeven,  0.5, 0);
  TEST(roundeven,  -0.5, 0);
  TEST(roundeven,  6, 6);
  TEST(roundeven,  -8, -8);
  TEST(roundeven,  2.5, 2);
  TEST(roundeven,  3.5, 4);
  TEST(roundeven,  -1.5, -2);
  TEST(roundeven,  3.499, 3);
  TEST(roundeven,  3.501, 4);

  return 0;
}

After checking for test case in the build directory using :
$ make check-gcc RUNTESTFLAGS="dg-torture.exp=builtin-round-roundeven.c"
test does not FAIL. Though, it FAILs for intentionally giving wrong RESULT.

Ex : TEST(roundeven,  3.501, 3);
Should fail I believe and thus giving output as:
FAIL: gcc.dg/torture/builtin-round-roundeven.c   -O0  (test for excess errors)
FAIL: gcc.dg/torture/builtin-round-roundeven.c   -O1  (test for excess errors)
FAIL: gcc.dg/torture/builtin-round-roundeven.c   -O2  (test for excess errors)
FAIL: gcc.dg/torture/builtin-round-roundeven.c   -O3 -g  (test for
excess errors)
FAIL: gcc.dg/torture/builtin-round-roundeven.c   -Os  (test for excess errors)
FAIL: gcc.dg/torture/builtin-round-roundeven.c   -O2 -flto
-fno-use-linker-plugin -flto-partition=none  (test for excess errors)
FAIL: gcc.dg/torture/builtin-round-roundeven.c   -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects  (test for excess errors)

Is this the way test cases should be added and checked?

Thanks.

On Wed, 8 May 2019 at 13:05, Tejas Joshi  wrote:
>
> Hello.
> I can't figure out from the documentation how to add test cases in the
> testsuite and inspect the results. How can I do that? Although, Taking
> the mentioned conditions under consideration, I have made another
> patch, attached.
>
> Thanks,
> -Tejas
>
>
> On Wed, 8 May 2019 at 09:01, Tejas Joshi  wrote:
> >
> > I should have taken all the test cases into consideration. Fool of me. I 
> > will try to make changes taking all the test cases into consideration along 
> > with the testsuite.
> > Thanks.
> >
> > On Wed, 8 May 2019 at 02:31, Joseph Myers  wrote:
> >>
> >> On Wed, 8 May 2019, Tejas Joshi wrote:
> >>
> >> > Hello.
> >> > As per my understanding, 3.5 would be represented in GCC as follows :
> >> > r->uexp  = 2
> >> > and
> >> > r->sig[2] = 11100 in binary 64 bit. (first 2 bits being 3 and
> >> > following 10000 being 0.5, which later only happens for halfway 
> >> > cases)
> >> > So, if we clear out the significand part and the immediate bit to the 
> >> > right
> >> > which represent 0.5, the entire significand would become 0 due to 
> >> > bit-wise
> >> > ANDing.
> >> >
> >> > > +  tempsig[w] &= (((unsigned long)1 << ((n % HOST_BITS_PER_LONG) - 1)) 
> >> > > -
> >> > > 1);
> >> > >
> >> >
> >> > That is what the following line intend to do. The clearing part would
> >> > change the significand, that's why significand was copied to a temporary
> >>
> >> That much is fine.  My issues are two other things:
> >>
> >> * The function would wrongly return true for 3, not just for 3.5, because
> >> it never checks the bit representing 0.5.  (If you don't care what it
> >> returns for 3, see my previous point about every function needing a
> >> comment defining its semantics.  Without such a comment, I have to guess,
> >> and my guess here is that the function should return true for 3.5 but
> >> false for 3 and for 3.5000...0001.)
> >>
> >> * The function would wrongly return true for 3.5000...0001, if there are
> >> enough 0s that all those low bits in sig[2] are 0, but some low bits in
> >> sig[1] or sig[0] are not 0.
> >>
> >> And also:
> >>
> >> * You should never need to modify parts of (a copy of) the significand in
> >> place.  Compare low parts of the significand (masked as needed) with 0.
> >> If not 0, just return false.  Likewise for comparing the 0.5 bit with 1.
> >> It's not that copying and modifying in place results in incorrect logic,
> >> it's simply excessively convoluted compared to things like:
> >>
> >>   if ((something & mask) != 0)
> >> return false
> >>
> >> (the function is probably twice as long as necessary because of that
> >> c

Re: About GSOC.

[Tejas Joshi]

Hello.
My exams are finally over and I have started to address these points now. I
intend to give my most of the time cause of holidays and will try to
consider most of the cases for the patch this time .

Thanks,
-Tejas

On Tue, 21 May 2019 at 03:18, Joseph Myers  wrote:

> On Mon, 20 May 2019, Martin Jambor wrote:
>
> > in addition to the things already pointed out by Joseph, I have the
> > following comments.  But as Joseph has already pointed out, you should
> > also test your patch on __float128 types, so please make sure your code
> > gets invoked and works for something like:
> >
> > if (__builtin_roundevenf128 (0x1p64q+0.5) != (0x1p64q))
> >   link_error (__LINE__);
>
>  ... but with the f128 constant suffix not q, so it works on more
> architectures (all those with _Float128 support, not just those with older
> __float128 support).
>
> > > +DEF_EXT_LIB_BUILTIN(BUILT_IN_ROUNDEVEN, "roundeven",
> BT_FN_DOUBLE_DOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
> > > +DEF_EXT_LIB_BUILTIN(BUILT_IN_ROUNDEVENF, "roundevenf",
> BT_FN_FLOAT_FLOAT, ATTR_CONST_NOTHROW_LEAF_LIST)
> > > +DEF_EXT_LIB_BUILTIN(BUILT_IN_ROUNDEVENL, "roundevenl",
> BT_FN_LONGDOUBLE_LONGDOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
> >
> > ...and for the code to trigger for __builtin_roundevenf128 you have to
> > define this builtin function too.  The easiest way is to do it in the
> > same way it is done for BUILTIN_ROUND and many other functions, i.e. use
> > DEF_EXT_LIB_FLOATN_NX_BUILTINS.
>
> Also note that TS 18661-1 has been merged into C2X.  I haven't yet updated
> glibc headers to reflect this, but this means a new DEF_C2X_BUILTIN should
> be added similar to DEF_C11_BUILTIN, and used for those three new
> functions, instead of DEF_EXT_LIB_BUILTIN.  (And for the strdup and
> strndup built-in functions, also added to C2X, but that's independent of
> the present project.)
>
> --
> Joseph S. Myers
> jos...@codesourcery.com
>

Re: About GSOC.

[Tejas Joshi]

Hello.
I tried to check the values for significand words using _Float128
using a test program with value larger than 64 bit.
Test program :

int main ()
{
_Float128 x = 18446744073709551617.5;   (i.e. 2^64 + 1.5 which is
certainly longer than 64-bit)
_Float128 y = __builtin_roundf128 (x);
}

The lower words of significand (sig[1] and sig[0] for 64-bit system)
are still being zero. I haven't included the roundevenf128 yet but
inspecting this on real_round function.
Am I missing something here?

Thanks.


On Wed, 29 May 2019 at 16:56, Tejas Joshi  wrote:
>
> Hello.
> My exams are finally over and I have started to address these points now. I 
> intend to give my most of the time cause of holidays and will try to consider 
> most of the cases for the patch this time .
>
> Thanks,
> -Tejas
>
> On Tue, 21 May 2019 at 03:18, Joseph Myers  wrote:
>>
>> On Mon, 20 May 2019, Martin Jambor wrote:
>>
>> > in addition to the things already pointed out by Joseph, I have the
>> > following comments.  But as Joseph has already pointed out, you should
>> > also test your patch on __float128 types, so please make sure your code
>> > gets invoked and works for something like:
>> >
>> > if (__builtin_roundevenf128 (0x1p64q+0.5) != (0x1p64q))
>> >   link_error (__LINE__);
>>
>>  ... but with the f128 constant suffix not q, so it works on more
>> architectures (all those with _Float128 support, not just those with older
>> __float128 support).
>>
>> > > +DEF_EXT_LIB_BUILTIN(BUILT_IN_ROUNDEVEN, "roundeven", 
>> > > BT_FN_DOUBLE_DOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
>> > > +DEF_EXT_LIB_BUILTIN(BUILT_IN_ROUNDEVENF, "roundevenf", 
>> > > BT_FN_FLOAT_FLOAT, ATTR_CONST_NOTHROW_LEAF_LIST)
>> > > +DEF_EXT_LIB_BUILTIN(BUILT_IN_ROUNDEVENL, "roundevenl", 
>> > > BT_FN_LONGDOUBLE_LONGDOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
>> >
>> > ...and for the code to trigger for __builtin_roundevenf128 you have to
>> > define this builtin function too.  The easiest way is to do it in the
>> > same way it is done for BUILTIN_ROUND and many other functions, i.e. use
>> > DEF_EXT_LIB_FLOATN_NX_BUILTINS.
>>
>> Also note that TS 18661-1 has been merged into C2X.  I haven't yet updated
>> glibc headers to reflect this, but this means a new DEF_C2X_BUILTIN should
>> be added similar to DEF_C11_BUILTIN, and used for those three new
>> functions, instead of DEF_EXT_LIB_BUILTIN.  (And for the strdup and
>> strndup built-in functions, also added to C2X, but that's independent of
>> the present project.)
>>
>> --
>> Joseph S. Myers
>> jos...@codesourcery.com

Re: About GSOC.

[Tejas Joshi]

Hello.
The f128 suffix worked. Based on all the corrections you all pointed
out, I have created another patch. I think I took most of the things
under consideration but please mention if I missed anything. The
following test cases were inspected with this patch. I am not sure if
the second test case is supposed to be carried out like I did.

Thanks,
-Tejas

/* { dg-do link } */

extern int link_error (int);

#define TEST(FN, VALUE, RESULT) \
  if (__builtin_##FN (VALUE) != RESULT) link_error (__LINE__);

int
main (void)
{
  TEST(roundeven,  0, 0);
  TEST(roundeven,  0.5, 0);
  TEST(roundeven,  -0.5, 0);
  TEST(roundeven,  6, 6);
  TEST(roundeven,  -8, -8);
  TEST(roundeven,  2.5, 2);
  TEST(roundeven,  3.5, 4);
  TEST(roundeven,  -1.5, -2);
  TEST(roundeven,  3.499, 3);
  TEST(roundeven,  3.501, 4);

  return 0;
}

second test case :

/* { dg-do link } */
/* { dg-add-options float128 } */
/* { dg-require-effective-target float128 } */

extern int link_error (int);

#define TEST(FN, VALUE, RESULT) \
  if (__builtin_##FN (VALUE) != RESULT) link_error (__LINE__);

int
main (void)
{
  TEST(roundevenf128,  (0x1p64+0.5), (0x1p64));

  return 0;
}

On Fri, 31 May 2019 at 15:41, Martin Jambor  wrote:
>
> On Thu, May 30 2019, Segher Boessenkool wrote:
> > On Thu, May 30, 2019 at 07:08:45PM +0200, Martin Jambor wrote:
> >> Interesting, I was also puzzled for a moment.  But notice that:
> >>
> >> int main ()
> >> {
> >> _Float128 x = 18446744073709551617.5f128;
> >> _Float128 y = __builtin_roundf128 (x);
> >> }
> >>
> >> behaves as expected... the difference is of course the suffix pegged to
> >> the literal constant (see
> >> https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gcc/Floating-Types.html).
> >>
> >> I would also expect GCC to use a larger type if a constant does not fit
> >> into a double, but apparently that does not happen.  I would have to
> >> check but it is probably the right behavior according to the standard.
> >
> > 6.4.4.2/4: "An unsuffixed floating constant has type double."  I don't
> > think your suggestion would be okay?
>
> Sorry if I was not clear but I was definitely not suggesting that we
> change this (or anything).  I wrote that I was also surprised but
> believed that GCC was doing the correct thing.
>
> Thanks for pointing out where exactly the standard says what has to be
> done though.
>
> Martin
diff --git a/gcc/builtins.c b/gcc/builtins.c
index 25e01e4092b..0b2d6bf82f9 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -2067,6 +2067,7 @@ mathfn_built_in_2 (tree type, combined_fn fn)
 CASE_MATHFN (REMQUO)
 CASE_MATHFN_FLOATN (RINT)
 CASE_MATHFN_FLOATN (ROUND)
+CASE_MATHFN (ROUNDEVEN)
 CASE_MATHFN (SCALB)
 CASE_MATHFN (SCALBLN)
 CASE_MATHFN (SCALBN)
diff --git a/gcc/builtins.def b/gcc/builtins.def
index ef89729fd0c..f284a3eae3b 100644
--- a/gcc/builtins.def
+++ b/gcc/builtins.def
@@ -542,12 +542,18 @@ DEF_C99_BUILTIN(BUILT_IN_RINTL, "rintl", BT_FN_LONGDOUBLE_LONGDOUBLE, AT
 #define RINT_TYPE(F) BT_FN_##F##_##F
 DEF_EXT_LIB_FLOATN_NX_BUILTINS (BUILT_IN_RINT, "rint", RINT_TYPE, ATTR_CONST_NOTHROW_LEAF_LIST)
 #undef RINT_TYPE
+DEF_EXT_LIB_BUILTIN(BUILT_IN_ROUNDEVEN, "roundeven", BT_FN_DOUBLE_DOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
+DEF_EXT_LIB_BUILTIN(BUILT_IN_ROUNDEVENF, "roundevenf", BT_FN_FLOAT_FLOAT, ATTR_CONST_NOTHROW_LEAF_LIST)
+DEF_EXT_LIB_BUILTIN(BUILT_IN_ROUNDEVENL, "roundevenl", BT_FN_LONGDOUBLE_LONGDOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_C99_BUILTIN(BUILT_IN_ROUND, "round", BT_FN_DOUBLE_DOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_C99_BUILTIN(BUILT_IN_ROUNDF, "roundf", BT_FN_FLOAT_FLOAT, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_C99_BUILTIN(BUILT_IN_ROUNDL, "roundl", BT_FN_LONGDOUBLE_LONGDOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
 #define ROUND_TYPE(F) BT_FN_##F##_##F
 DEF_EXT_LIB_FLOATN_NX_BUILTINS (BUILT_IN_ROUND, "round", ROUND_TYPE, ATTR_CONST_NOTHROW_LEAF_LIST)
 #undef ROUND_TYPE
+#define ROUNDEVEN_TYPE(F) BT_FN_##F##_##F
+DEF_EXT_LIB_FLOATN_NX_BUILTINS (BUILT_IN_ROUNDEVEN, "roundeven", ROUNDEVEN_TYPE, ATTR_CONST_NOTHROW_LEAF_LIST)
+#undef ROUNDEVEN_TYPE
 DEF_EXT_LIB_BUILTIN(BUILT_IN_SCALB, "scalb", BT_FN_DOUBLE_DOUBLE_DOUBLE, ATTR_MATHFN_FPROUNDING_ERRNO)
 DEF_EXT_LIB_BUILTIN(BUILT_IN_SCALBF, "scalbf", BT_FN_FLOAT_FLOAT_FLOAT, ATTR_MATHFN_FPROUNDING_ERRNO)
 DEF_EXT_LIB_BUILTIN(BUILT_IN_SCALBL, "scalbl", BT_FN_LONGDOUBLE_LONGDOUBLE_LONGDOUBLE, ATTR_MATHFN_FPROUNDING_ERRNO)
diff --git a/gcc/fold-const-call.c b/gcc/fold-const-call.c
index 06a420601c0..54315d057a2 100644
--- a/gcc/fold-const-call.c
+++ b/gcc/fold-const-call.c
@@ -792,6 +792,15 @@ fold_const_call_ss (real_value *result, combined_fn fn,
 	}
   return false;
 
+CASE_CFN_ROUNDEVEN:
+CASE_CFN_ROUNDEVEN_FN:
+  if (!REAL_VALUE_ISNAN (*arg) || !flag_errno_math)
+  {
+real_roundeven (result, format, arg);
+return true;
+  }
+  return false;
+
 CASE_CFN_LOGB:
   return fold_const_logb (result, arg, format);
 

Re: About GSOC.

[Tejas Joshi]

Hello.
I have already sent a patch for roundeven implementation but I do not
know how do I commit my changes to GCC. Am I supposed to create a
branch or anything etc?
Also I have been trying to do folding for constant arguments and
inspecting for only func (func (x)) -> func (x) right now. I made some
changes to make this work including like :
+(for fns (TRUNC_ALL FLOOR_ALL CEIL_ALL ROUND_ALL ROUNDEVEN_ALL
NEARBYINT_ALL RINT_ALL)

Also, BUILT_IN_ROUNDEVEN instead of ROUNDEVEN_ALL is not working here.
Other changes regarding to this after inspecting round are included in
this patch, but this seems not working and I am surely missing
something. Do I need to include roundeven like round:

DEFINE_INT_AND_FLOAT_ROUND_FN (ROUND)

but this would require defining IROUNDEVEN in builtins.def but it is
not supposed to?

Thanks,
--Tejas

On Fri, 31 May 2019 at 19:00, Eric Gallager  wrote:
>
> On 5/31/19, Nathan Sidwell  wrote:
> > On 5/30/19 5:38 PM, Segher Boessenkool wrote:
> >> On Thu, May 30, 2019 at 07:08:45PM +0200, Martin Jambor wrote:
> >>> Interesting, I was also puzzled for a moment.  But notice that:
> >>>
> >>> int main ()
> >>> {
> >>>  _Float128 x = 18446744073709551617.5f128;
> >>>  _Float128 y = __builtin_roundf128 (x);
> >>> }
> >>>
> >>> behaves as expected... the difference is of course the suffix pegged to
> >>> the literal constant (see
> >>> https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gcc/Floating-Types.html).
> >>>
> >>> I would also expect GCC to use a larger type if a constant does not fit
> >>> into a double, but apparently that does not happen.  I would have to
> >>> check but it is probably the right behavior according to the standard.
> >>
> >> 6.4.4.2/4: "An unsuffixed floating constant has type double."  I don't
> >> think your suggestion would be okay?
> >
> > Not only that, but
> >
> > 1) there isn't a literal suffix to mean 'double', so one couldn't
> > override that extended type.
>
> There's not a standard one, but there is 'D' or 'd' as a GNU
> extension. The fact that it's nonstandard, though, is what causes some
> projects to ignore -Wunsuffixed-float-constants:
> https://lists.gnu.org/archive/html/bug-gzip/2011-11/msg00017.html
>
> > 2) how do you define 'doesn't fit'?  decimal 0.1 has a recurring binary
> > representation.  Should that become the longest floating point type?
> >
> > nathan
> >
> > --
> > Nathan Sidwell
> >
diff --git a/gcc/builtins.c b/gcc/builtins.c
index 25e01e4092b..0b2d6bf82f9 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -2067,6 +2067,7 @@ mathfn_built_in_2 (tree type, combined_fn fn)
 CASE_MATHFN (REMQUO)
 CASE_MATHFN_FLOATN (RINT)
 CASE_MATHFN_FLOATN (ROUND)
+CASE_MATHFN (ROUNDEVEN)
 CASE_MATHFN (SCALB)
 CASE_MATHFN (SCALBLN)
 CASE_MATHFN (SCALBN)
diff --git a/gcc/builtins.def b/gcc/builtins.def
index ef89729fd0c..f284a3eae3b 100644
--- a/gcc/builtins.def
+++ b/gcc/builtins.def
@@ -542,12 +542,18 @@ DEF_C99_BUILTIN(BUILT_IN_RINTL, "rintl", BT_FN_LONGDOUBLE_LONGDOUBLE, AT
 #define RINT_TYPE(F) BT_FN_##F##_##F
 DEF_EXT_LIB_FLOATN_NX_BUILTINS (BUILT_IN_RINT, "rint", RINT_TYPE, ATTR_CONST_NOTHROW_LEAF_LIST)
 #undef RINT_TYPE
+DEF_EXT_LIB_BUILTIN(BUILT_IN_ROUNDEVEN, "roundeven", BT_FN_DOUBLE_DOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
+DEF_EXT_LIB_BUILTIN(BUILT_IN_ROUNDEVENF, "roundevenf", BT_FN_FLOAT_FLOAT, ATTR_CONST_NOTHROW_LEAF_LIST)
+DEF_EXT_LIB_BUILTIN(BUILT_IN_ROUNDEVENL, "roundevenl", BT_FN_LONGDOUBLE_LONGDOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_C99_BUILTIN(BUILT_IN_ROUND, "round", BT_FN_DOUBLE_DOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_C99_BUILTIN(BUILT_IN_ROUNDF, "roundf", BT_FN_FLOAT_FLOAT, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_C99_BUILTIN(BUILT_IN_ROUNDL, "roundl", BT_FN_LONGDOUBLE_LONGDOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
 #define ROUND_TYPE(F) BT_FN_##F##_##F
 DEF_EXT_LIB_FLOATN_NX_BUILTINS (BUILT_IN_ROUND, "round", ROUND_TYPE, ATTR_CONST_NOTHROW_LEAF_LIST)
 #undef ROUND_TYPE
+#define ROUNDEVEN_TYPE(F) BT_FN_##F##_##F
+DEF_EXT_LIB_FLOATN_NX_BUILTINS (BUILT_IN_ROUNDEVEN, "roundeven", ROUNDEVEN_TYPE, ATTR_CONST_NOTHROW_LEAF_LIST)
+#undef ROUNDEVEN_TYPE
 DEF_EXT_LIB_BUILTIN(BUILT_IN_SCALB, "scalb", BT_FN_DOUBLE_DOUBLE_DOUBLE, ATTR_MATHFN_FPROUNDING_ERRNO)
 DEF_EXT_LIB_BUILTIN(BUILT_IN_SCALBF, "scalbf", BT_FN_FLOAT_FLOAT_FLOAT, ATTR_MATHFN_FPROUNDING_ERRNO)
 DEF_EXT_LIB_BUILTIN(BUILT_IN_SCALBL, "scalbl", BT_FN_LONGDOUBLE_LONGDOUBLE_LONGDOUBLE, ATTR_MATHFN_FPROUNDING_ERRNO)
diff --git a/gcc/fold-const-call.c b/gcc/fold-const-call.c
index 06a420601c0..54315d057a2 100644
--- a/gcc/fold-const-call.c
+++ b/gcc/fold-const-call.c
@@ -792,6 +792,15 @@ fold_const_call_ss (real_value *result, combined_fn fn,
 	}
   return false;
 
+CASE_CFN_ROUNDEVEN:
+CASE_CFN_ROUNDEVEN_FN:
+  if (!REAL_VALUE_ISNAN (*arg) || !flag_errno_math)
+  {
+real_roundeven (result, format, arg);
+return true;
+  }
+  return false;
+
 CASE_CFN_LOGB:
   return fold

Re: About GSOC.

[Tejas Joshi]

Hello.

> NaN, and you should make sure it behaves accordingly.  (If it should never
> be called for them, a gcc_assert would be appropriate.)

I can't find any documentation about how and when to use gcc_assert.
But I used it looking at the comment at its definition and locations
it is used, is this appropriate? Or is it supposed to be used before
calling the function? :

+bool
+is_even (REAL_VALUE_TYPE *r)
+{
+  /* The function is not supposed to use for Inf and NaN. */
+  gcc_assert (r->cl != rvc_inf);
+  gcc_assert (r->cl != rvc_nan);

> So n is the bit position, and w is the word position, of the bit with
> value 1; n-1 is the position of the bit with value 0.5.
> If n is a multiple of HOST_BITS_PER_LONG (that is, the bits with values
> 0.5 and 1 are in different words), this will incorrectly return false when
> the 0.5 bit is set.

I did not understand this. What is the bit with value 1?
But when n is a multiple of HOST_BITS_PER_LONG, the function was
computing value of w wrong (e.g. for number 2^63 + 0.5). At such time,
would the following improvisation be acceptable in is_halfway_below?

+bool
+is_halfway_below (const REAL_VALUE_TYPE *r)
+{
+  /* The function is not supposed to use for Inf and NaN. */
+  gcc_assert (r->cl != rvc_inf);
+  gcc_assert (r->cl != rvc_nan);
+  int i;
+
+  /* For numbers (-0.5,0) and (0,0.5). */
+  if (REAL_EXP (r) < 0)
+return false;
+
+  else if (REAL_EXP (r) <= SIGNIFICAND_BITS)
+  {
+unsigned int n = SIGNIFICAND_BITS - REAL_EXP (r);
+int w = n / HOST_BITS_PER_LONG;
+
+if (n % HOST_BITS_PER_LONG == 0)
+{
+  if (w > 0)
+w = w - 1;
+  else
+w = 0;
+}
+
+for (i = 0; i < w; ++i)
+{
+  if (r->sig[i] != 0)
+return false;
+}

Thanks.


On Mon, 3 Jun 2019 at 22:08, Joseph Myers  wrote:
>
> On Fri, 31 May 2019, Tejas Joshi wrote:
>
> > +/* Return true if integer part of R is even, else return false. */
> > +
> > +bool
> > +is_even (REAL_VALUE_TYPE *r)
> > +{
> > +  if (REAL_EXP (r) <= 0)
> > +return false;
>
> But the integer part (truncation towards 0) of something in the interval
> (-1, 1) is of course even.
>
> > +  else if (REAL_EXP (r) < SIGNIFICAND_BITS)
> > +  {
> > +unsigned int n = SIGNIFICAND_BITS - REAL_EXP (r);
> > +int w = n / HOST_BITS_PER_LONG;
> > +
> > +unsigned long num = ((unsigned long)1 << (n % HOST_BITS_PER_LONG));
> > +
> > +if ((r->sig[w] & num) == 0)
> > +  return true;
> > +  }
> > +  return false;
> > +}
>
> Suppose REAL_EXP (r) == SIGNIFICAND_BITS.  Then you still need to check
> the low bit in that case.
>
> Suppose REAL_EXP (r) > SIGNIFICAND_BITS.  Then the number is definitely
> even, so you should return true, not false.
>
> The comment on this function needs to define what it does for infinity /
> NaN, and you should make sure it behaves accordingly.  (If it should never
> be called for them, a gcc_assert would be appropriate.)
>
> What does this function do for zero?  It should, of course, return that it
> is even.
>
> > +/* Return true if R is halfway between two integers, else return false. */
>
> Again, define what this does for infinity / NaN and make sure it behaves
> accordingly.
>
> > +bool
> > +is_halfway_below (const REAL_VALUE_TYPE *r)
> > +{
> > +  if (REAL_EXP (r) < 0)
> > +return false;
> > +
> > +  if (REAL_EXP (r) == 0)
> > +  {
> > +unsigned long temp = ((unsigned long)1 << 63);
>
> unsigned long might be 32-bit; you can't assume it's 64-bit.  You may mean
> (HOST_BITS_PER_LONG - 1) instead of 63.
>
> > +if (((r->sig[SIGSZ-1] & temp) != 0) && ((r->sig[SIGSZ-1] & (temp-1)) 
> > == 0))
> > +  return true;
> > +else
> > +  return false;
>
> This appears only to be checking the high word, not lower bits.
>
> > +  else if (REAL_EXP (r) < SIGNIFICAND_BITS)
> > +  {
> > +unsigned int n = SIGNIFICAND_BITS - REAL_EXP (r);
> > +int i, w = n / HOST_BITS_PER_LONG;
>
> So n is the bit position, and w is the word position, of the bit with
> value 1; n-1 is the position of the bit with value 0.5.
>
> > +for (i = 0; i < w; ++i)
> > +{
> > +  if (r->sig[i] != 0)
> > +return false;
> > +}
>
> If n is a multiple of HOST_BITS_PER_LONG (that is, the bits with values
> 0.5 and 1 are in different words), this will incorrectly return false when
> the 0.5 bit is set.
>
> > +unsigned long num = ((unsigned long)1 << ((n - 1) % 
> > HOST_BITS_PER_LONG));
> > +
> > +if (((

Re: About GSOC.

[Tejas Joshi]

Hello.
Following patch is tested on following test cases in the testsuite and
tests did not fail. I have considered most of the test cases this time
hopefully.

/* { dg-do link } */

extern int link_error (int);

#define TEST(FN, VALUE, RESULT) \
  if (__builtin_##FN (VALUE) != RESULT) link_error (__LINE__);

int
main (void)
{
  TEST(roundeven,  0, 0);
  TEST(roundeven,  0.5, 0);
  TEST(roundeven,  -0.5, 0);
  TEST(roundeven,  6, 6);
  TEST(roundeven,  -8, -8);
  TEST(roundeven,  2.5, 2);
  TEST(roundeven,  3.5, 4);
  TEST(roundeven,  -1.5, -2);
  TEST(roundeven,  3.499, 3);
  TEST(roundeven,  3.501, 4);

  return 0;
}
_Float128 test cases :

/* { dg-do link } */
/* { dg-add-options float128 } */
/* { dg-require-effective-target float128 } */

extern int link_error (int);

#define TEST(FN, VALUE, RESULT) \
  if (__builtin_##FN##f128 (VALUE) != RESULT) link_error (__LINE__);

int
main (void)
{
  TEST(roundeven,  (0x1p64+0.5f128), (0x1p64f128));
  TEST(roundeven,  (0x1p63+0.5f128), (0x1p63f128));
  TEST(roundeven,  (0x1p63-0.5f128), (0x1p63f128));
  TEST(roundeven,  (0x1p64-0.5f128), (0x1p64f128));
  TEST(roundeven,  (0x1p64+0.501f128), (0x1p64+1.0f128));
  TEST(roundeven,  (0x1.C39A5653p1f128), (0x1p2f128))
// the hex number is 3.5000...01 which would fail for roundeven
but not for f128
  return 0;
}

Thanks,
-Tejas

On Tue, 4 Jun 2019 at 12:38, Tejas Joshi  wrote:
>
> Hello.
>
> > NaN, and you should make sure it behaves accordingly.  (If it should never
> > be called for them, a gcc_assert would be appropriate.)
>
> I can't find any documentation about how and when to use gcc_assert.
> But I used it looking at the comment at its definition and locations
> it is used, is this appropriate? Or is it supposed to be used before
> calling the function? :
>
> +bool
> +is_even (REAL_VALUE_TYPE *r)
> +{
> +  /* The function is not supposed to use for Inf and NaN. */
> +  gcc_assert (r->cl != rvc_inf);
> +  gcc_assert (r->cl != rvc_nan);
>
> > So n is the bit position, and w is the word position, of the bit with
> > value 1; n-1 is the position of the bit with value 0.5.
> > If n is a multiple of HOST_BITS_PER_LONG (that is, the bits with values
> > 0.5 and 1 are in different words), this will incorrectly return false when
> > the 0.5 bit is set.
>
> I did not understand this. What is the bit with value 1?
> But when n is a multiple of HOST_BITS_PER_LONG, the function was
> computing value of w wrong (e.g. for number 2^63 + 0.5). At such time,
> would the following improvisation be acceptable in is_halfway_below?
>
> +bool
> +is_halfway_below (const REAL_VALUE_TYPE *r)
> +{
> +  /* The function is not supposed to use for Inf and NaN. */
> +  gcc_assert (r->cl != rvc_inf);
> +  gcc_assert (r->cl != rvc_nan);
> +  int i;
> +
> +  /* For numbers (-0.5,0) and (0,0.5). */
> +  if (REAL_EXP (r) < 0)
> +return false;
> +
> +  else if (REAL_EXP (r) <= SIGNIFICAND_BITS)
> +  {
> +unsigned int n = SIGNIFICAND_BITS - REAL_EXP (r);
> +int w = n / HOST_BITS_PER_LONG;
> +
> +if (n % HOST_BITS_PER_LONG == 0)
> +{
> +  if (w > 0)
> +w = w - 1;
> +  else
> +w = 0;
> +}
> +
> +for (i = 0; i < w; ++i)
> +{
> +  if (r->sig[i] != 0)
> +return false;
> +}
>
> Thanks.
>
>
> On Mon, 3 Jun 2019 at 22:08, Joseph Myers  wrote:
> >
> > On Fri, 31 May 2019, Tejas Joshi wrote:
> >
> > > +/* Return true if integer part of R is even, else return false. */
> > > +
> > > +bool
> > > +is_even (REAL_VALUE_TYPE *r)
> > > +{
> > > +  if (REAL_EXP (r) <= 0)
> > > +return false;
> >
> > But the integer part (truncation towards 0) of something in the interval
> > (-1, 1) is of course even.
> >
> > > +  else if (REAL_EXP (r) < SIGNIFICAND_BITS)
> > > +  {
> > > +unsigned int n = SIGNIFICAND_BITS - REAL_EXP (r);
> > > +int w = n / HOST_BITS_PER_LONG;
> > > +
> > > +unsigned long num = ((unsigned long)1 << (n % HOST_BITS_PER_LONG));
> > > +
> > > +if ((r->sig[w] & num) == 0)
> > > +  return true;
> > > +  }
> > > +  return false;
> > > +}
> >
> > Suppose REAL_EXP (r) == SIGNIFICAND_BITS.  Then you still need to check
> > the low bit in that case.
> >
> > Suppose REAL_EXP (r) > SIGNIFICAND_BITS.  Then the number is definitely
> > even, so you should return true, not false.
> >
> > The comment on this function needs to define what it does for infinity /
> > NaN, and you should make sure it behaves accordingly.  (If

Re: About GSOC.

[Tejas Joshi]

Hello.
I have created another patch which addresses the above points,
attached herewith.

> a conditional with < not <=; if REAL_EXP (r) == SIGNIFICAND_BITS, the
> least significant bit has value 1 and the number must be an integer).

The number is integer because of the whole word spaces is occupied by
integer part?
Also, why would the least significant bit will have value 1 if
REAL_EXP (r) == SIGNIFICAND_BITS, as it only concerns with 2^0th
position (even or odd)?

Thanks,
-Tejas


On Thu, 6 Jun 2019 at 22:13, Joseph Myers  wrote:
>
> On Tue, 4 Jun 2019, Tejas Joshi wrote:
>
> > Hello.
> >
> > > NaN, and you should make sure it behaves accordingly.  (If it should never
> > > be called for them, a gcc_assert would be appropriate.)
> >
> > I can't find any documentation about how and when to use gcc_assert.
> > But I used it looking at the comment at its definition and locations
> > it is used, is this appropriate? Or is it supposed to be used before
> > calling the function? :
> >
> > +bool
> > +is_even (REAL_VALUE_TYPE *r)
> > +{
> > +  /* The function is not supposed to use for Inf and NaN. */
> > +  gcc_assert (r->cl != rvc_inf);
> > +  gcc_assert (r->cl != rvc_nan);
>
> I'd suggest making the comment above the function be clear about what
> classes of arguments are or are not valid, and then you don't need a
> comment on the assertions.
>
> Is REAL_EXP meaningful for rvc_zero?  If not, you should check for
> rvc_zero and handle it appropriately before doing anything checking
> REAL_EXP.
>
> > > So n is the bit position, and w is the word position, of the bit with
> > > value 1; n-1 is the position of the bit with value 0.5.
> > > If n is a multiple of HOST_BITS_PER_LONG (that is, the bits with values
> > > 0.5 and 1 are in different words), this will incorrectly return false when
> > > the 0.5 bit is set.
> >
> > I did not understand this. What is the bit with value 1?
>
> I don't understand your question.  The "sig" array contains
> SIGNIFICAND_BITS bits.  The most significant one has value 2^(REAL_EXP-1)
> and thus the least significant one has value
> 2^(REAL_EXP-SIGNIFICAND_BITS).  The ones we care about for the present
> purposes are the bit with value 1 (to tell whether an integer part is even
> or odd), the bit with value 0.5 and all the bits lower than that (to tell
> whether the fractional part is exactly 0.5 or not).
>
> > But when n is a multiple of HOST_BITS_PER_LONG, the function was
> > computing value of w wrong (e.g. for number 2^63 + 0.5). At such time,
> > would the following improvisation be acceptable in is_halfway_below?
>
> That still seems wrong.
>
> For testing for a halfway value you don't care about the bit with value 1.
> You do care about the bit with value 0.5, and you do care about the lower
> bits.
>
> So you should probably set n = SIGNIFICAND_BITS - REAL_EXP (r) - 1 (under
> a conditional with < not <=; if REAL_EXP (r) == SIGNIFICAND_BITS, the
> least significant bit has value 1 and the number must be an integer).
> That way, n is the bit position of the bit with value 0.5.  Then you can
> compute w from n without special casing to get the word position of the
> bit with value 0.5.  For the words below w you check they are entirely 0.
> For word w you need to check both that bit n is 1 and the lower bits are
> 0.
>
> --
> Joseph S. Myers
> jos...@codesourcery.com
diff --git a/gcc/builtins.c b/gcc/builtins.c
index 25e01e4092b..0b2d6bf82f9 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -2067,6 +2067,7 @@ mathfn_built_in_2 (tree type, combined_fn fn)
 CASE_MATHFN (REMQUO)
 CASE_MATHFN_FLOATN (RINT)
 CASE_MATHFN_FLOATN (ROUND)
+CASE_MATHFN (ROUNDEVEN)
 CASE_MATHFN (SCALB)
 CASE_MATHFN (SCALBLN)
 CASE_MATHFN (SCALBN)
diff --git a/gcc/builtins.def b/gcc/builtins.def
index ef89729fd0c..f284a3eae3b 100644
--- a/gcc/builtins.def
+++ b/gcc/builtins.def
@@ -542,12 +542,18 @@ DEF_C99_BUILTIN(BUILT_IN_RINTL, "rintl", BT_FN_LONGDOUBLE_LONGDOUBLE, AT
 #define RINT_TYPE(F) BT_FN_##F##_##F
 DEF_EXT_LIB_FLOATN_NX_BUILTINS (BUILT_IN_RINT, "rint", RINT_TYPE, ATTR_CONST_NOTHROW_LEAF_LIST)
 #undef RINT_TYPE
+DEF_EXT_LIB_BUILTIN(BUILT_IN_ROUNDEVEN, "roundeven", BT_FN_DOUBLE_DOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
+DEF_EXT_LIB_BUILTIN(BUILT_IN_ROUNDEVENF, "roundevenf", BT_FN_FLOAT_FLOAT, ATTR_CONST_NOTHROW_LEAF_LIST)
+DEF_EXT_LIB_BUILTIN(BUILT_IN_ROUNDEVENL, "roundevenl", BT_FN_LONGDOUBLE_LONGDOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_C99_BUILTIN(BUILT_IN_ROUND, "round", BT_FN_DOUBLE_DOUBLE, ATTR_CONST_NOTHROW_LEAF_LI

Re: Committing patches and other conventions (Was: Re: About GSOC)

[Tejas Joshi]

Thank you for this mail.
As soon as the implementation of roundeven is approved, I will do the
documentation in ChangeLogs wherever necessary and the testing part.
Will also make changes where my code does not match the GCC coding
conventions and will try to follow it further.

Thanks.
-Tejas

On Thu, 6 Jun 2019 at 22:26, Martin Jambor  wrote:
>
> Hi,
>
> On Mon, Jun 03 2019, Tejas Joshi wrote:
> > Hello.
> > I have already sent a patch for roundeven implementation but I do not
> > know how do I commit my changes to GCC. Am I supposed to create a
> > branch or anything etc?
>
> You don't have to create a branch unless you think it would make ease
> your own workflow.  Once a patch is ready to go and has been explicitely
> approved by a corresponding maintainer, you will be expected to commit
> it directly to svn (we'll ask for a svn write access for you when we get
> to that point).  You'll find the list of maintainers in the MAINTAINERS
> file of the gcc repository, I believe your patches will need approval
> from a global reviewer, most probably Joseph.
>
> Before that happens, the code must be of course considered correct but
> also must adhere to some conventions, please see
> https://gcc.gnu.org/codingconventions.html.  Your patches so far lacked
> a ChangeLog and testcases.  Have a look at what other do when they post
> patches to gcc-patches: https://gcc.gnu.org/ml/gcc-patches/2019-06/
>
> ChangeLog has to have the given, fairly strict format, but should be
> very brief.  When posting patches, you don't make it part of the patch
> even though when committing, you are expected it to prepend the
> corresponding ChangeLog file with your bit (see e.g. gcc/ChangeLog and
> gcc/testsuite/ChangeLog).
>
> You have always stated how you tested your patches but you are actually
> supposed to add the testsuite and committed along with the functional
> patch, so that other can then test they do not regress on the
> functionality you have just added.
>
> That is why everybody including you has to test their patches also by
> doing:
>
> make bootstrap
> make -k check
>
> (with a -j level appropriate for your computer) and then collect *.sum
> files from unpatched and patched runs and compare them (see script in
> contrib/compare_tests) to make sure they did not introduce any
> regressions.
>
> See section on "Testing patches" at https://gcc.gnu.org/contribute.html
> for more details.
>
> Please ask about these mechanisms and conventions if anything is not
> clear.  I'll go and find the latest version of your roundeven patch and
> see if I can help you a little (but I am likely to finish that only
> tomorrow morning).
>
> Thanks,
>
> Martin

Re: Committing patches and other conventions (Was: Re: About GSOC)

[Tejas Joshi]

Hello.
Is this the correct sequence for regression test:
1. Revert back all the changes I made and then configure, build along with
make bootstrap
make -k check
collect the *.sum files
2. Apply the patch and do the configuration, build as above 1 and then
collect the *.sum files and compare them.

How do I collect and inspect these *.sum files?

Thanks,
-Tejas

On Thu, 6 Jun 2019 at 22:26, Martin Jambor  wrote:
>
> Hi,
>
> On Mon, Jun 03 2019, Tejas Joshi wrote:
> > Hello.
> > I have already sent a patch for roundeven implementation but I do not
> > know how do I commit my changes to GCC. Am I supposed to create a
> > branch or anything etc?
>
> You don't have to create a branch unless you think it would make ease
> your own workflow.  Once a patch is ready to go and has been explicitely
> approved by a corresponding maintainer, you will be expected to commit
> it directly to svn (we'll ask for a svn write access for you when we get
> to that point).  You'll find the list of maintainers in the MAINTAINERS
> file of the gcc repository, I believe your patches will need approval
> from a global reviewer, most probably Joseph.
>
> Before that happens, the code must be of course considered correct but
> also must adhere to some conventions, please see
> https://gcc.gnu.org/codingconventions.html.  Your patches so far lacked
> a ChangeLog and testcases.  Have a look at what other do when they post
> patches to gcc-patches: https://gcc.gnu.org/ml/gcc-patches/2019-06/
>
> ChangeLog has to have the given, fairly strict format, but should be
> very brief.  When posting patches, you don't make it part of the patch
> even though when committing, you are expected it to prepend the
> corresponding ChangeLog file with your bit (see e.g. gcc/ChangeLog and
> gcc/testsuite/ChangeLog).
>
> You have always stated how you tested your patches but you are actually
> supposed to add the testsuite and committed along with the functional
> patch, so that other can then test they do not regress on the
> functionality you have just added.
>
> That is why everybody including you has to test their patches also by
> doing:
>
> make bootstrap
> make -k check
>
> (with a -j level appropriate for your computer) and then collect *.sum
> files from unpatched and patched runs and compare them (see script in
> contrib/compare_tests) to make sure they did not introduce any
> regressions.
>
> See section on "Testing patches" at https://gcc.gnu.org/contribute.html
> for more details.
>
> Please ask about these mechanisms and conventions if anything is not
> clear.  I'll go and find the latest version of your roundeven patch and
> see if I can help you a little (but I am likely to finish that only
> tomorrow morning).
>
> Thanks,
>
> Martin

Re: About GSOC.

[Tejas Joshi]

Hello.

> I don't think you should have the unreachable "return false;" in is_even.
> The last "else if" can just be "else".

I don't think return false in is_even is unreachable. As per my
understanding, when one else if is true in the else if ladder, all the
subsequent "else ifs" including "else" are ignored. When REAL_EXP is
less than SIGNIFICAND_BITS, but the number is odd, the inner "if" for
even-odd will not return true in which case should return false. That
case will ignore next "else if" and will reach return false.

> Suppose REAL_EXP (r) > SIGNIFICAND_BITS.  Then the number is definitely
> even, so you should return true, not false.

for this condition, else if can be modified to just else and return true.
PATCH:

gcc/ChangeLog:

2019-06-12  Tejas Joshi  

* builtins.c (mathfn_built_in_2): Added CASE_MATHFN for ROUNDEVEN.
* builtins.def: Added function definitions for roundeven function
variants.
* fold-const-call.c (fold_const_call_ss): Added case for function
call and fold_const_conversion call for roundeven function.
* fold-const.c (negate_mathfn_p): Added case for roundeven function.
(tree_call_nonnegative_warnv_p): Added case for roundeven function.
(integer_valued_real_call_p): Added case for roundeven function.
* real.c (is_even): New function. Returns true if real number is
even, otherwise returns false.
(is_halfway_below): New function. Returns true if real number is
halfway between two integers, else return false.
(real_roundeven): New function. Round real number to nearest
integer, rounding halfway cases towards even.
* real.h (real_value): Added descriptive comments.
Added function declaration for roundeven function.

gcc/testsuite/ChangeLog:

2019-06-12  Tejas Joshi  

* gcc.dg/torture/builtin-round-roundeven.c: New test.
* gcc.dg/torture/builtin-round-roundevenf128.c: New test.



On Tue, 11 Jun 2019 at 01:56, Joseph Myers  wrote:
>
> On Sun, 9 Jun 2019, Tejas Joshi wrote:
>
> > Hello.
> > I have created another patch which addresses the above points,
> > attached herewith.
>
> I don't think you should have the unreachable "return false;" in is_even.
> The last "else if" can just be "else".
>
> > > a conditional with < not <=; if REAL_EXP (r) == SIGNIFICAND_BITS, the
> > > least significant bit has value 1 and the number must be an integer).
> >
> > The number is integer because of the whole word spaces is occupied by
> > integer part?
> > Also, why would the least significant bit will have value 1 if
> > REAL_EXP (r) == SIGNIFICAND_BITS, as it only concerns with 2^0th
> > position (even or odd)?
>
> My understanding is that the significand is, as per the comments in
> real.c, in the range [0.5, 1.0).  There are SIGNIFICAND_BITS bits.  The
> bit above the most significant one has value 2^REAL_EXP.  The most
> significant one has value 2^(REAL_EXP-1).  The least significant one has
> value 2^(REAL_EXP-SIGNIFICAND_BITS).  If REAL_EXP == SIGNIFICAND_BITS,
> that means the least significant bit has value 2^0 = 1, and there are no
> bits with value 0.5 or below, so the number is an integer.
>
> --
> Joseph S. Myers
> jos...@codesourcery.com
diff --git a/gcc/builtins.c b/gcc/builtins.c
index 3463ffb1539..85a945877a4 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -2085,6 +2085,7 @@ mathfn_built_in_2 (tree type, combined_fn fn)
 CASE_MATHFN (REMQUO)
 CASE_MATHFN_FLOATN (RINT)
 CASE_MATHFN_FLOATN (ROUND)
+CASE_MATHFN (ROUNDEVEN)
 CASE_MATHFN (SCALB)
 CASE_MATHFN (SCALBLN)
 CASE_MATHFN (SCALBN)
diff --git a/gcc/builtins.def b/gcc/builtins.def
index 6d41bdb4f44..8bb7027aac7 100644
--- a/gcc/builtins.def
+++ b/gcc/builtins.def
@@ -542,12 +542,18 @@ DEF_C99_BUILTIN(BUILT_IN_RINTL, "rintl", BT_FN_LONGDOUBLE_LONGDOUBLE, AT
 #define RINT_TYPE(F) BT_FN_##F##_##F
 DEF_EXT_LIB_FLOATN_NX_BUILTINS (BUILT_IN_RINT, "rint", RINT_TYPE, ATTR_CONST_NOTHROW_LEAF_LIST)
 #undef RINT_TYPE
+DEF_EXT_LIB_BUILTIN(BUILT_IN_ROUNDEVEN, "roundeven", BT_FN_DOUBLE_DOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
+DEF_EXT_LIB_BUILTIN(BUILT_IN_ROUNDEVENF, "roundevenf", BT_FN_FLOAT_FLOAT, ATTR_CONST_NOTHROW_LEAF_LIST)
+DEF_EXT_LIB_BUILTIN(BUILT_IN_ROUNDEVENL, "roundevenl", BT_FN_LONGDOUBLE_LONGDOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_C99_BUILTIN(BUILT_IN_ROUND, "round", BT_FN_DOUBLE_DOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_C99_BUILTIN(BUILT_IN_ROUNDF, "roundf", BT_FN_FLOAT_FLOAT, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_C99_BUILTIN(BUILT_IN_ROUNDL, "roundl", BT_FN_LONGDOUBLE_LONGDOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
 #define ROUND_TYPE(F) BT_FN_#

Re: About GSOC.

[Tejas Joshi]

Hello.
As further part of implementing roundeven is inlining, I was studying
machine descriptions and I have a few questions.

As suggested, builtin functions provided a strong model for
implementing roundeven. Keeping that in mind, I tried to inspect how
similar functions (round/ceil) would get inlined. As it is dependent
on target machine, (mine is i7, so should be x86_64 ? I wonder why
gcc/config/ does not have x86_64 or amd64 directory. Or is it i386
itself as extended?), should *.s file after compilation contain the
specific instruction if supported? I was unable to see such kind of
instruction on any -O level.

Different pattern names are available for machine descriptions
<https://gcc.gnu.org/onlinedocs/gccint/Standard-Names.html>, also for
round, ceil, etc. Will I have to add such pattern name for roundeven?
(is it the same as optab defined in optabs.def?)

Thanks,
-Tejas


On Thu, 13 Jun 2019 at 00:27, Tejas Joshi  wrote:
>
> Hello.
>
> > I don't think you should have the unreachable "return false;" in is_even.
> > The last "else if" can just be "else".
>
> I don't think return false in is_even is unreachable. As per my
> understanding, when one else if is true in the else if ladder, all the
> subsequent "else ifs" including "else" are ignored. When REAL_EXP is
> less than SIGNIFICAND_BITS, but the number is odd, the inner "if" for
> even-odd will not return true in which case should return false. That
> case will ignore next "else if" and will reach return false.
>
> > Suppose REAL_EXP (r) > SIGNIFICAND_BITS.  Then the number is definitely
> > even, so you should return true, not false.
>
> for this condition, else if can be modified to just else and return true.
> PATCH:
>
> gcc/ChangeLog:
>
> 2019-06-12  Tejas Joshi  
>
> * builtins.c (mathfn_built_in_2): Added CASE_MATHFN for ROUNDEVEN.
> * builtins.def: Added function definitions for roundeven function
> variants.
> * fold-const-call.c (fold_const_call_ss): Added case for function
> call and fold_const_conversion call for roundeven function.
> * fold-const.c (negate_mathfn_p): Added case for roundeven function.
> (tree_call_nonnegative_warnv_p): Added case for roundeven function.
> (integer_valued_real_call_p): Added case for roundeven function.
> * real.c (is_even): New function. Returns true if real number is
> even, otherwise returns false.
> (is_halfway_below): New function. Returns true if real number is
> halfway between two integers, else return false.
> (real_roundeven): New function. Round real number to nearest
>     integer, rounding halfway cases towards even.
> * real.h (real_value): Added descriptive comments.
> Added function declaration for roundeven function.
>
> gcc/testsuite/ChangeLog:
>
> 2019-06-12  Tejas Joshi  
>
> * gcc.dg/torture/builtin-round-roundeven.c: New test.
> * gcc.dg/torture/builtin-round-roundevenf128.c: New test.
>
>
>
> On Tue, 11 Jun 2019 at 01:56, Joseph Myers  wrote:
> >
> > On Sun, 9 Jun 2019, Tejas Joshi wrote:
> >
> > > Hello.
> > > I have created another patch which addresses the above points,
> > > attached herewith.
> >
> > I don't think you should have the unreachable "return false;" in is_even.
> > The last "else if" can just be "else".
> >
> > > > a conditional with < not <=; if REAL_EXP (r) == SIGNIFICAND_BITS, the
> > > > least significant bit has value 1 and the number must be an integer).
> > >
> > > The number is integer because of the whole word spaces is occupied by
> > > integer part?
> > > Also, why would the least significant bit will have value 1 if
> > > REAL_EXP (r) == SIGNIFICAND_BITS, as it only concerns with 2^0th
> > > position (even or odd)?
> >
> > My understanding is that the significand is, as per the comments in
> > real.c, in the range [0.5, 1.0).  There are SIGNIFICAND_BITS bits.  The
> > bit above the most significant one has value 2^REAL_EXP.  The most
> > significant one has value 2^(REAL_EXP-1).  The least significant one has
> > value 2^(REAL_EXP-SIGNIFICAND_BITS).  If REAL_EXP == SIGNIFICAND_BITS,
> > that means the least significant bit has value 2^0 = 1, and there are no
> > bits with value 0.5 or below, so the number is an integer.
> >
> > --
> > Joseph S. Myers
> > jos...@codesourcery.com

Re: Expanding roundeven (Was: Re: About GSOC.)

[Tejas Joshi]

> Of course the instruction is not present there, that is the next step in
> your project :-)

Yes, of course, but what I meant was that instructions for existing
round/ceil functions and not roundeven. If inlining for these
functions is available, how can I inspect such instructions getting
inlined maybe in a *.s file?

Also, I am trying to find appropriate places to introduce changes for
roundeven to be inlined. Attached patch is what I have tried so far to
find the places.
ix86_expand_roundeven have dummy code for the sake of time.

In i386.md:
1. How should roundeven be defined at certain places where existing
floor is defined as:
(define_int_attr rounding_insn
[(UNSPEC_FRNDINT_FLOOR "floor")

2. Also, can roundeven be handled like round_floor is handled by:
(define_expand "2"
but definitely with certain changes of flags, options and macros.

Thanks,
--Tejas



On Thu, 13 Jun 2019 at 22:49, Martin Jambor  wrote:
>
> Hi Tejas,
>
> On Thu, Jun 13 2019, Tejas Joshi wrote:
> > Hello.
> > As further part of implementing roundeven is inlining, I was studying
> > machine descriptions and I have a few questions.
> >
> > As suggested, builtin functions provided a strong model for
> > implementing roundeven. Keeping that in mind, I tried to inspect how
> > similar functions (round/ceil) would get inlined. As it is dependent
> > on target machine, (mine is i7, so should be x86_64 ? I wonder why
> > gcc/config/ does not have x86_64 or amd64 directory. Or is it i386
> > itself as extended?),
>
> Yes, the directory with x86_64 specific stuff is i386.
>
> > should *.s file after compilation contain the
> > specific instruction if supported? I was unable to see such kind of
> > instruction on any -O level.
> >
>
> I am not sure I understand your question.  Yes, the intent is that when
> the compiler cannot determine the argument of roundeven to be constant,
> it should emit the instruction instead of a library call, if the target
> architecture supports it.  (and if IIUC, the intent is to use the 0 mode
> from table 4-8 in
> https://software.intel.com/sites/default/files/managed/39/c5/325462-sdm-vol-1-2abcd-3abcd.pdf
> in instructions that take a rounding a mode to implement roundeven).
>
> Of course the instruction is not present there, that is the next step in
> your project :-)
>
> > Different pattern names are available for machine descriptions
> > <https://gcc.gnu.org/onlinedocs/gccint/Standard-Names.html>, also for
> > round, ceil, etc. Will I have to add such pattern name for roundeven?
> > (is it the same as optab defined in optabs.def?)
>
> Yes.
>
> Martin
diff --git a/gcc/builtins.c b/gcc/builtins.c
index 85a945877a4..291717da7ee 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -2723,6 +2723,9 @@ expand_builtin_int_roundingfn (tree exp, rtx target)
   fallback_fn = BUILT_IN_FLOOR;
   break;
 
+CASE_FLT_FN (BUILT_IN_ROUNDEVEN):
+  builtin_optab = roundeven_optab;
+
 default:
   gcc_unreachable ();
 }
@@ -7346,6 +7349,7 @@ expand_builtin (tree exp, rtx target, rtx subtarget, machine_mode mode,
 	return target;
   break;
 
+CASE_FLT_FN (BUILT_IN_ROUNDEVEN):
 CASE_FLT_FN (BUILT_IN_ICEIL):
 CASE_FLT_FN (BUILT_IN_LCEIL):
 CASE_FLT_FN (BUILT_IN_LLCEIL):
diff --git a/gcc/config/i386/i386-builtin.def b/gcc/config/i386/i386-builtin.def
index e547dda80f1..5cd255d24ef 100644
--- a/gcc/config/i386/i386-builtin.def
+++ b/gcc/config/i386/i386-builtin.def
@@ -902,6 +902,7 @@ BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundps, "__builtin_ia32_round
 BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundsd, "__builtin_ia32_roundsd", IX86_BUILTIN_ROUNDSD, UNKNOWN, (int) V2DF_FTYPE_V2DF_V2DF_INT)
 BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundss, "__builtin_ia32_roundss", IX86_BUILTIN_ROUNDSS, UNKNOWN, (int) V4SF_FTYPE_V4SF_V4SF_INT)
 
+BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundevenpd, "__builtin_ia32_roundevenpd", IX86_BUILTIN_ROUNDEVENPD, (enum rtx_code) ROUND_ROUNDEVEN, (int) V2DF_FTYPE_V2DF_ROUND)
 BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundpd, "__builtin_ia32_floorpd", IX86_BUILTIN_FLOORPD, (enum rtx_code) ROUND_FLOOR, (int) V2DF_FTYPE_V2DF_ROUND)
 BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundpd, "__builtin_ia32_ceilpd", IX86_BUILTIN_CEILPD, (enum rtx_code) ROUND_CEIL, (int) V2DF_FTYPE_V2DF_ROUND)
 BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundpd, "__builtin_ia32_truncpd", IX86_BUILTIN_TRUNCPD, (enum rtx_code) ROUND_TRUNC, (int) V2DF_FTYPE_V2DF_ROUND)
@@ -913,6 +914,7 @@ BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundpd_vec_pack_sfix, "__buil
 BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_roundv2df2, "__builtin_ia32_roundpd

Re: Expanding roundeven (Was: Re: About GSOC.)

[Tejas Joshi]

Hello.
Looking at machine description of functions like ceil/floor and I
think specifically:

(define_expand "2"

Roundeven should be described as define_expand (or within this
alongside ceil and floor?) with expand functions to emit instructions
in i386-builtins.c?
Referring to ,
operands of these instructions work with xmm registers, memory and
imm8 for rounding mode.

> existing ROUND_NO_EXC definition in GCC.  A new definition will need
> adding alongside ROUND_FLOOR, ROUND_CEIL and ROUND_TRUNC to correspond to
> rounding to nearest with ties to even, evaluating to 0.)

So (ROUND_ROUNDEVEN   0x0) be declared for rounding towards nearest
even for rounding mode argument? But reference says that RC field
should end up as 00B for rounding ties to even? I am also much
confused about machine-type flags used as C conditions. How do we
determine which ones to check and does it depends on exceptions and
conditions described in the reference? Also, do ROUNDEVEN needs to be
defined as (how):

(define_int_attr rounding_insn
[(UNSPEC_FRNDINT_FLOOR "floor")

Thanks,
--Tejas


On Fri, 14 Jun 2019 at 23:02, Martin Jambor  wrote:
>
> Hi,
>
> On Fri, Jun 14 2019, Tejas Joshi wrote:
> >> Of course the instruction is not present there, that is the next step in
> >> your project :-)
> >
> > Yes, of course, but what I meant was that instructions for existing
> > round/ceil functions and not roundeven. If inlining for these
> > functions is available, how can I inspect such instructions getting
> > inlined maybe in a *.s file?
>
> Make sure you compile to a target that has the rounding instruction,
> i.e. by using an appropriate -march or -mavx) and also specify
> -ffast-math on the command line.  I have not double checked, but I
> assume the latter is necessary (mainly) because it implies
> -fno-math-errno and most of the math builtin expansion into instructions
> is guarded by check for !flag_errno_math.
>
> So e.g. my test input:
>
>   double
>   callplusone (double d)
>   {
> return __builtin_round (d) + 1;
>   }
>
> has vroundsd instruction in the output of:
>
>   ~/gcc/trunk/inst/bin/gcc -O2 -S expand_example.c -mavx -ffast-math
>
> >
> > Also, I am trying to find appropriate places to introduce changes for
> > roundeven to be inlined. Attached patch is what I have tried so far to
> > find the places.
>
> So far I only quickly glanced over it but it seems to be going in the
> right direction.  I'll try to answer the rest of your questions as soon
> as I can but I also have to look a bit into the machine descriptions
> myself first.
>
> Martin
>
>
> > ix86_expand_roundeven have dummy code for the sake of time.
> >
> > In i386.md:
> > 1. How should roundeven be defined at certain places where existing
> > floor is defined as:
> > (define_int_attr rounding_insn
> > [(UNSPEC_FRNDINT_FLOOR "floor")
> >
> > 2. Also, can roundeven be handled like round_floor is handled by:
> > (define_expand "2"
> > but definitely with certain changes of flags, options and macros.
> >
> > Thanks,
> > --Tejas

Re: Expanding roundeven (Was: Re: About GSOC.)

[Tejas Joshi]

Hello.
I have made following changes to inspect inlining of roundeven with
the following test code:
double
plusone (double d)
{
return __builtin_roundeven (d) + 1;
}

Running the program using -O2 foo.c gave internal compiler error which
I believe is because gcc_unreachable() at:

if (TARGET_SSE4_1)
emit_insn (gen_sse4_1_round2
   (operands[0], operands[1], GEN_INT (ROUND_
   | ROUND_NO_EXC)));
I think the following condition matches the criterion? :
> I think the code will be much clearer if it explicitly says
> ROUND_ROUNDEVEN | ROUND_NO_EXC,

 else if (TARGET_64BIT || (mode != DFmode))
{
  if (ROUND_ == ROUND_FLOOR)
ix86_expand_floorceil (operands[0], operands[1], true);
  else if (ROUND_ == ROUND_CEIL)
ix86_expand_floorceil (operands[0], operands[1], false);
  else if (ROUND_ == ROUND_TRUNC)
ix86_expand_trunc (operands[0], operands[1]);
  else
gcc_unreachable ();
}
in:
(define_expand "2"
But with -mavx, generated the vroundsd insn. Does it mean ROUNDEVEN
should have a condition in the else if, but comments above
ix86_expand* functions in i386-expand.c says that those are for SSE2
sequences?

Thanks,
--Tejas


On Mon, 17 Jun 2019 at 22:45, Joseph Myers  wrote:
>
> On Mon, 17 Jun 2019, Tejas Joshi wrote:
>
> > > existing ROUND_NO_EXC definition in GCC.  A new definition will need
> > > adding alongside ROUND_FLOOR, ROUND_CEIL and ROUND_TRUNC to correspond to
> > > rounding to nearest with ties to even, evaluating to 0.)
> >
> > So (ROUND_ROUNDEVEN   0x0) be declared for rounding towards nearest
> > even for rounding mode argument? But reference says that RC field
> > should end up as 00B for rounding ties to even? I am also much
>
> I think the code will be much clearer if it explicitly says
> ROUND_ROUNDEVEN | ROUND_NO_EXC, than if it hardcodes implicit knowledge
> that 0 is the value used for rounding to nearest with ties to even.
>
> --
> Joseph S. Myers
> jos...@codesourcery.com
diff --git a/gcc/config/i386/i386-builtin.def b/gcc/config/i386/i386-builtin.def
index e547dda80f1..40536d7929c 100644
--- a/gcc/config/i386/i386-builtin.def
+++ b/gcc/config/i386/i386-builtin.def
@@ -906,6 +906,7 @@ BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundpd, "__builtin_ia32_floor
 BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundpd, "__builtin_ia32_ceilpd", IX86_BUILTIN_CEILPD, (enum rtx_code) ROUND_CEIL, (int) V2DF_FTYPE_V2DF_ROUND)
 BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundpd, "__builtin_ia32_truncpd", IX86_BUILTIN_TRUNCPD, (enum rtx_code) ROUND_TRUNC, (int) V2DF_FTYPE_V2DF_ROUND)
 BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundpd, "__builtin_ia32_rintpd", IX86_BUILTIN_RINTPD, (enum rtx_code) ROUND_MXCSR, (int) V2DF_FTYPE_V2DF_ROUND)
+BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundpd, "__builtin_ia32_roundevenpd", IX86_BUILTIN_ROUNDEVENPD, (enum rtx_code) ROUND_ROUNDEVEN, (int) V2DF_FTYPE_V2DF_ROUND)
 
 BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundpd_vec_pack_sfix, "__builtin_ia32_floorpd_vec_pack_sfix", IX86_BUILTIN_FLOORPD_VEC_PACK_SFIX, (enum rtx_code) ROUND_FLOOR, (int) V4SI_FTYPE_V2DF_V2DF_ROUND)
 BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundpd_vec_pack_sfix, "__builtin_ia32_ceilpd_vec_pack_sfix", IX86_BUILTIN_CEILPD_VEC_PACK_SFIX, (enum rtx_code) ROUND_CEIL, (int) V4SI_FTYPE_V2DF_V2DF_ROUND)
@@ -917,6 +918,7 @@ BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundps, "__builtin_ia32_floor
 BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundps, "__builtin_ia32_ceilps", IX86_BUILTIN_CEILPS, (enum rtx_code) ROUND_CEIL, (int) V4SF_FTYPE_V4SF_ROUND)
 BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundps, "__builtin_ia32_truncps", IX86_BUILTIN_TRUNCPS, (enum rtx_code) ROUND_TRUNC, (int) V4SF_FTYPE_V4SF_ROUND)
 BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundps, "__builtin_ia32_rintps", IX86_BUILTIN_RINTPS, (enum rtx_code) ROUND_MXCSR, (int) V4SF_FTYPE_V4SF_ROUND)
+BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundps, "__builtin_ia32_roundevenps", IX86_BUILTIN_ROUNDEVENPS, (enum rtx_code) ROUND_ROUNDEVEN, (int) V4SF_FTYPE_V4SF_ROUND)
 
 BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundps_sfix, "__builtin_ia32_floorps_sfix", IX86_BUILTIN_FLOORPS_SFIX, (enum rtx_code) ROUND_FLOOR, (int) V4SI_FTYPE_V4SF_ROUND)
 BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundps_sfix, "__builtin_ia32_ceilps_sfix", IX86_BUILTIN_CEILPS_SFIX, (enum rtx_code) ROUND_CEIL, (int) V4SI_FTYPE_V4SF_ROUND)
diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
index 01213ccb82c..ce58b5e5c28 100644
--- a/gcc/config/i386/i386.h
+++ b/gcc/config/i386/i386.h
@@ -2468,6 +2468,7 @@ enum ix86_stack_slot
   SLOT_CW_T

Re: Expanding roundeven (Was: Re: About GSOC.)

[Tejas Joshi]

Hello.
I have already sent a patch for expanding roundeven for i386 with
relevant doubts. I also was regression testing with
make -k check
after successful bootstrap build with reverting my patches. Turns out
do-check fails without any patches applied, Is it ok to do anyways for
applied patch? Also, /contrib/compare_tests returns with "no common
files to compare" but I see all as the same files (actually, I am
moving *.sum files in manual directory and comparing with build of
applied patch.)? Is it due to failed make check?

Thanks,
-Tejas


On Wed, 19 Jun 2019 at 19:07, Tejas Joshi  wrote:
>
> Hello.
> I have made following changes to inspect inlining of roundeven with
> the following test code:
> double
> plusone (double d)
> {
> return __builtin_roundeven (d) + 1;
> }
>
> Running the program using -O2 foo.c gave internal compiler error which
> I believe is because gcc_unreachable() at:
>
> if (TARGET_SSE4_1)
> emit_insn (gen_sse4_1_round2
>(operands[0], operands[1], GEN_INT (ROUND_
>| ROUND_NO_EXC)));
> I think the following condition matches the criterion? :
> > I think the code will be much clearer if it explicitly says
> > ROUND_ROUNDEVEN | ROUND_NO_EXC,
>
>  else if (TARGET_64BIT || (mode != DFmode))
> {
>   if (ROUND_ == ROUND_FLOOR)
> ix86_expand_floorceil (operands[0], operands[1], true);
>   else if (ROUND_ == ROUND_CEIL)
> ix86_expand_floorceil (operands[0], operands[1], false);
>   else if (ROUND_ == ROUND_TRUNC)
> ix86_expand_trunc (operands[0], operands[1]);
>   else
> gcc_unreachable ();
> }
> in:
> (define_expand "2"
> But with -mavx, generated the vroundsd insn. Does it mean ROUNDEVEN
> should have a condition in the else if, but comments above
> ix86_expand* functions in i386-expand.c says that those are for SSE2
> sequences?
>
> Thanks,
> --Tejas
>
>
> On Mon, 17 Jun 2019 at 22:45, Joseph Myers  wrote:
> >
> > On Mon, 17 Jun 2019, Tejas Joshi wrote:
> >
> > > > existing ROUND_NO_EXC definition in GCC.  A new definition will need
> > > > adding alongside ROUND_FLOOR, ROUND_CEIL and ROUND_TRUNC to correspond 
> > > > to
> > > > rounding to nearest with ties to even, evaluating to 0.)
> > >
> > > So (ROUND_ROUNDEVEN   0x0) be declared for rounding towards nearest
> > > even for rounding mode argument? But reference says that RC field
> > > should end up as 00B for rounding ties to even? I am also much
> >
> > I think the code will be much clearer if it explicitly says
> > ROUND_ROUNDEVEN | ROUND_NO_EXC, than if it hardcodes implicit knowledge
> > that 0 is the value used for rounding to nearest with ties to even.
> >
> > --
> > Joseph S. Myers
> > jos...@codesourcery.com
diff --git a/gcc/config/i386/i386-builtin.def b/gcc/config/i386/i386-builtin.def
index e547dda80f1..40536d7929c 100644
--- a/gcc/config/i386/i386-builtin.def
+++ b/gcc/config/i386/i386-builtin.def
@@ -906,6 +906,7 @@ BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundpd, "__builtin_ia32_floor
 BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundpd, "__builtin_ia32_ceilpd", IX86_BUILTIN_CEILPD, (enum rtx_code) ROUND_CEIL, (int) V2DF_FTYPE_V2DF_ROUND)
 BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundpd, "__builtin_ia32_truncpd", IX86_BUILTIN_TRUNCPD, (enum rtx_code) ROUND_TRUNC, (int) V2DF_FTYPE_V2DF_ROUND)
 BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundpd, "__builtin_ia32_rintpd", IX86_BUILTIN_RINTPD, (enum rtx_code) ROUND_MXCSR, (int) V2DF_FTYPE_V2DF_ROUND)
+BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundpd, "__builtin_ia32_roundevenpd", IX86_BUILTIN_ROUNDEVENPD, (enum rtx_code) ROUND_ROUNDEVEN, (int) V2DF_FTYPE_V2DF_ROUND)
 
 BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundpd_vec_pack_sfix, "__builtin_ia32_floorpd_vec_pack_sfix", IX86_BUILTIN_FLOORPD_VEC_PACK_SFIX, (enum rtx_code) ROUND_FLOOR, (int) V4SI_FTYPE_V2DF_V2DF_ROUND)
 BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundpd_vec_pack_sfix, "__builtin_ia32_ceilpd_vec_pack_sfix", IX86_BUILTIN_CEILPD_VEC_PACK_SFIX, (enum rtx_code) ROUND_CEIL, (int) V4SI_FTYPE_V2DF_V2DF_ROUND)
@@ -917,6 +918,7 @@ BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundps, "__builtin_ia32_floor
 BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundps, "__builtin_ia32_ceilps", IX86_BUILTIN_CEILPS, (enum rtx_code) ROUND_CEIL, (int) V4SF_FTYPE_V4SF_ROUND)
 BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundps, "__builtin_ia32_truncps", IX86_BUILTIN_TRUNCPS, (enum rtx_code) ROUND_TRUNC, (int) V4SF_FTYPE_V4SF_ROUND)
 BDESC (O

[GSoC-19] Expanding Roundeven

[Tejas Joshi]

Hello.
This was a mail in thread  Re: Expanding roundeven on 19th June but as
its gone far inside the thread, I thought of having a fresh one. The
following patch expands roundeven with instruction vroundsd using
-mavx option but without it is giving internal compiler error which I
believe is due to reaching gcc_unreachable (). The doubts I had come
up with :
Test code compiled with attached patch:

double
plusone (double d)
{
return __builtin_roundeven (d) + 1;
}

Compiling the program using -O2 gave internal compiler error which
I believe is because gcc_unreachable() at:

Inside :
(define_expand "2"

There is a condition :

if (TARGET_SSE4_1)
emit_insn (gen_sse4_1_round2
   (operands[0], operands[1], GEN_INT (ROUND_
   | ROUND_NO_EXC)));

I think the above condition matches the criterion which Joseph
previously mentioned? :
> I think the code will be much clearer if it explicitly says
> ROUND_ROUNDEVEN | ROUND_NO_EXC,

 else if (TARGET_64BIT || (mode != DFmode))
{
  if (ROUND_ == ROUND_FLOOR)
ix86_expand_floorceil (operands[0], operands[1], true);
  else if (ROUND_ == ROUND_CEIL)
ix86_expand_floorceil (operands[0], operands[1], false);
  else if (ROUND_ == ROUND_TRUNC)
ix86_expand_trunc (operands[0], operands[1]);
  else
gcc_unreachable ();
}

But with -mavx option, assembly generated the vroundsd insn. Does it
mean ROUNDEVEN
should have a condition in the above else if, but comments above
ix86_expand* functions in i386-expand.c says that those are for SSE2
sequences?

Thanks,
-Tejas
diff --git a/gcc/config/i386/i386-builtin.def b/gcc/config/i386/i386-builtin.def
index e547dda80f1..40536d7929c 100644
--- a/gcc/config/i386/i386-builtin.def
+++ b/gcc/config/i386/i386-builtin.def
@@ -906,6 +906,7 @@ BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundpd, "__builtin_ia32_floor
 BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundpd, "__builtin_ia32_ceilpd", IX86_BUILTIN_CEILPD, (enum rtx_code) ROUND_CEIL, (int) V2DF_FTYPE_V2DF_ROUND)
 BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundpd, "__builtin_ia32_truncpd", IX86_BUILTIN_TRUNCPD, (enum rtx_code) ROUND_TRUNC, (int) V2DF_FTYPE_V2DF_ROUND)
 BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundpd, "__builtin_ia32_rintpd", IX86_BUILTIN_RINTPD, (enum rtx_code) ROUND_MXCSR, (int) V2DF_FTYPE_V2DF_ROUND)
+BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundpd, "__builtin_ia32_roundevenpd", IX86_BUILTIN_ROUNDEVENPD, (enum rtx_code) ROUND_ROUNDEVEN, (int) V2DF_FTYPE_V2DF_ROUND)
 
 BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundpd_vec_pack_sfix, "__builtin_ia32_floorpd_vec_pack_sfix", IX86_BUILTIN_FLOORPD_VEC_PACK_SFIX, (enum rtx_code) ROUND_FLOOR, (int) V4SI_FTYPE_V2DF_V2DF_ROUND)
 BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundpd_vec_pack_sfix, "__builtin_ia32_ceilpd_vec_pack_sfix", IX86_BUILTIN_CEILPD_VEC_PACK_SFIX, (enum rtx_code) ROUND_CEIL, (int) V4SI_FTYPE_V2DF_V2DF_ROUND)
@@ -917,6 +918,7 @@ BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundps, "__builtin_ia32_floor
 BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundps, "__builtin_ia32_ceilps", IX86_BUILTIN_CEILPS, (enum rtx_code) ROUND_CEIL, (int) V4SF_FTYPE_V4SF_ROUND)
 BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundps, "__builtin_ia32_truncps", IX86_BUILTIN_TRUNCPS, (enum rtx_code) ROUND_TRUNC, (int) V4SF_FTYPE_V4SF_ROUND)
 BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundps, "__builtin_ia32_rintps", IX86_BUILTIN_RINTPS, (enum rtx_code) ROUND_MXCSR, (int) V4SF_FTYPE_V4SF_ROUND)
+BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundps, "__builtin_ia32_roundevenps", IX86_BUILTIN_ROUNDEVENPS, (enum rtx_code) ROUND_ROUNDEVEN, (int) V4SF_FTYPE_V4SF_ROUND)
 
 BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundps_sfix, "__builtin_ia32_floorps_sfix", IX86_BUILTIN_FLOORPS_SFIX, (enum rtx_code) ROUND_FLOOR, (int) V4SI_FTYPE_V4SF_ROUND)
 BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundps_sfix, "__builtin_ia32_ceilps_sfix", IX86_BUILTIN_CEILPS_SFIX, (enum rtx_code) ROUND_CEIL, (int) V4SI_FTYPE_V4SF_ROUND)
diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
index 01213ccb82c..ce58b5e5c28 100644
--- a/gcc/config/i386/i386.h
+++ b/gcc/config/i386/i386.h
@@ -2468,6 +2468,7 @@ enum ix86_stack_slot
   SLOT_CW_TRUNC,
   SLOT_CW_FLOOR,
   SLOT_CW_CEIL,
+  SLOT_CW_ROUNDEVEN,
   SLOT_STV_TEMP,
   MAX_386_STACK_LOCALS
 };
@@ -2479,6 +2480,7 @@ enum ix86_entity
   I387_TRUNC,
   I387_FLOOR,
   I387_CEIL,
+  I387_ROUNDEVEN,
   MAX_386_ENTITIES
 };
 
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 01338e294ab..b11af2f4308 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -144,6 +144,7 @@
   UNSPEC_FRNDINT_FLOOR
   UNSPEC_FRNDINT_CEIL
   UNSPEC_FRNDINT_TRUNC
+  UNSPEC_FRNDINT_ROUNDEVEN
   UNSPEC_FIST_FLOOR
   UNSPEC_FIST_CEIL
 
@@ -303,7 +304,8 @@
 
 ;; Constants to represent rounding modes in the ROUND instruct

[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

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  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
diff --git a/gcc/builtin-types.def b/gcc/builtin-types.def
index e5c9e063c48..47cb81006e0 100644
--- a/gcc/builtin-types.def
+++ b/gcc/builtin-types.def
@@ -387,6 +387,8 @@ DEF_FUNCTION_TYPE_2 (BT_FN_VOID_UINT_PTR,
 		 BT_VOID, BT_UINT, BT_PTR)
 DEF_FUNCTION_TYPE_2 (BT_FN_FLOAT_FLOAT_FLOAT,
 		 BT_FLOAT, BT_FLOAT, BT_FLOAT)
+DEF_FUNCTION_TYPE_2 (BT_FN_FLOAT_DOUBLE_DOUBLE,
+		 BT_FLOAT, BT_DOUBLE, BT_DOUBLE)
 DEF_FUNCTION_TYPE_2 (BT_FN_DOUBLE_DOUBLE_DOUBLE,
 		 BT_DOUBLE, BT_DOUBLE, BT_DOUBLE)
 DEF_FUNCTION_TYPE_2 (BT_FN_LONGDOUBLE_LONGDOUBLE_LONGDOUBLE,
diff --git a/gcc/builtins.c b/gcc/builtins.c
index 85a945877a4..371fb62b645 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -2035,6 +2035,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)
diff --git a/gcc/builtins.def b/gcc/builtins.def
index 8bb7027aac7..1d065eae345 100644
--- a/gcc/builtins.def
+++ b/gcc/builtins.def
@@ -352,6 +352,9 @@ 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_FADDF, "faddf", BT_FN_FLOAT_DOUBLE_DOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
+DEF_EXT_LIB_BUILTIN(BUILT_IN_FADDL, "faddl", BT_FN_FLOAT_DOUBLE_DOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
 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..ee939f85005 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);
+
 default:
   return false;
 }
diff --git a/gcc/real.c b/gcc/real.c
index ab71430709f..6379cd0bcdc 100644
--- a/gcc/real.c
+++ b/gcc/real.c
@@ -5093,6 +5093,17 @@ real_roundeven (REAL_VALUE_

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  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  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
diff --git a/gcc/builtin-types.def b/gcc/builtin-types.def
index e5c9e063c48..87ecd2e9218 100644
--- a/gcc/builtin-types.def
+++ b/gcc/builtin-types.def
@@ -387,6 +387,10 @@ DEF_FUNCTION_TYPE_2 (BT_FN_VOID_UINT_PTR,
 		 BT_VOID, BT_UINT, BT_PTR)
 DEF_FUNCTION_TYPE_2 (BT_FN_FLOAT_FLOAT_FLOAT,
 		 BT_FLOAT, BT_FLOAT, BT_FLOAT)
+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)
 DEF_FUNCTION_TYPE_2 (BT_FN_DOUBLE_DOUBLE_DOUBLE,
 		 BT_DOUBLE, BT_DOUBLE, BT_DOUBLE)
 DEF_FUNCTION_TYPE_2 (BT_FN_LONGDOUBLE_LONGDOUBLE_LONGDOUBLE,
diff --git a/gcc/builtins.c b/gcc/builtins.c
index f61f10422fd..471c7918abb 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)
diff --git a/gcc/builtins.def b/gcc/builtins.def
index 8bb7027aac7..afc482f38dc 100644
--- a/gcc/builtins.def
+++ b/gcc/builtins.def
@@ -352,6 +352,9 @@ 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_FADDF, "faddf", BT_FN_FLOAT_FLOAT_FLOAT, ATTR_CONST_NOTHROW_LEAF_LIST)
+DEF_EXT_LIB_BUILTIN(BUILT_IN_FADDL, "faddl", BT_FN_FLOAT_LONGDOUBLE_LONGDOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_GCC_BUILTIN(BUILT_IN_FABSD32, "fabsd32", BT_FN_DFLOAT32_DFLOAT32, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_GCC_BUILTIN(BUI

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
 wrote:
>
> Tejas Joshi  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
diff --git a/gcc/builtin-types.def b/gcc/builtin-types.def
index e5c9e063c48..6bc552fa71a 100644
--- a/gcc/builtin-types.def
+++ b/gcc/builtin-types.def
@@ -387,8 +387,14 @@ DEF_FUNCTION_TYPE_2 (BT_FN_VOID_UINT_PTR,
 		 BT_VOID, BT_UINT, BT_PTR)
 DEF_FUNCTION_TYPE_2 (BT_FN_FLOAT_FLOAT_FLOAT,
 		 BT_FLOAT, BT_FLOAT, BT_FLOAT)
+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)
 DEF_FUNCTION_TYPE_2 (BT_FN_DOUBLE_DOUBLE_DOUBLE,
 		 BT_DOUBLE, BT_DOUBLE, BT_DOUBLE)
+DEF_FUNCTION_TYPE_2 (BT_FN_DOUBLE_LONGDOUBLE_LONGDOUBLE,
+		 BT_DOUBLE, BT_LONGDOUBLE, BT_LONGDOUBLE)
 DEF_FUNCTION_TYPE_2 (BT_FN_LONGDOUBLE_LONGDOUBLE_LONGDOUBLE,
 		 BT_LONGDOUBLE, BT_LONGDOUBLE, BT_LONGDOUBLE)
 DEF_FUNCTION_TYPE_2 (BT_FN_FLOAT16_FLOAT16_FLOAT16,
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)
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
 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

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

[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  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, "f

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  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=0x7fffc580, fmt=..., x=0x77800060, 
> y=0x77800080)
> 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 = 0x92666400
> (gdb) n
> 5102real_convert (r, fmt, r);
> (gdb)
> 5103  return false;
> (gdb) p/x r->sig[2]
> $3 = 0x9200
> --
>
> Thanks,
>
> Martin
>
>

Re: Expansion of narrowing math built-ins into power instructions

[Tejas Joshi]

Hi,

> In GCC (in rs6000.md) we have the "*add3_fpr" and similar insns,
> which could be extended to allow DF inputs with an SF output; it doesn't
> yet allow it.

Thanks for the inputs, I will try to address these points now. I have
built GCC on gcc112 and will apply patch and test testcases there.

Tejas


On Wed, 31 Jul 2019 at 01:18, Joseph Myers  wrote:
>
> On Tue, 30 Jul 2019, Florian Weimer wrote:
>
> > * Martin Jambor:
> >
> > > as you might know, Tejas is our Google Summer of Code student working on
> > > adding built-in functions for some new math functions added in ISO/IEC
> > > TS 18661.
> > >
> > > His next step is to expand "functions rounding result to narrower type"
> > > (so fadd, fsub and possibly fmul and fdiv described in
> > > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2314.pdf) into ISA
> > > instructions on targets that have such instructions.
> >
> > Sorry, this might be a silly question, but: How do you plan to recognize
> > that the fadd/fsub being called is indeed the one from the TS?
>
> I expect it's the same as any other built-in function: compatible
> prototype plus appropriate options (-std=gnu*, or -std=c2x in future once
> we teach GCC that these functions are in C2x) that enable the built-in
> functions.
>
> --
> Joseph S. Myers
> jos...@codesourcery.com

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

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  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  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  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 t

Re: Expansion of narrowing math built-ins into power instructions

[Tejas Joshi]

Hi.
It took some time for me to finish with the folding part for fadd
variants and till it is reviewed, I want to move ahead with power8/9
expansions on top of the current fadd patch.

> In GCC (in rs6000.md) we have the "*add3_fpr" and similar insns,
> which could be extended to allow DF inputs with an SF output; it doesn't
> yet allow it.

This might be very lousy but I am confused with the optabs and insn
name rn, the comments in obtabs.def says that these patterns are
present in md as insn names. How can fadd function be mapped with the
"fadd3_fpr" pattern name?
Also, faddl and daddl functions take long double as argument, can they
also be expanded on DF to SF mode or only on QP float on power9?

I have built GCC and applied my current patches on gcc112 and yes, on
gcc135 too.

Thanks,
Tejas


On Wed, 31 Jul 2019 at 20:17, Segher Boessenkool
 wrote:
>
> On Wed, Jul 31, 2019 at 12:23:18PM +0530, Tejas Joshi wrote:
> > > In GCC (in rs6000.md) we have the "*add3_fpr" and similar insns,
> > > which could be extended to allow DF inputs with an SF output; it doesn't
> > > yet allow it.
> >
> > Thanks for the inputs, I will try to address these points now. I have
> > built GCC on gcc112 and will apply patch and test testcases there.
>
> For the QP float (binary128, KFmode, take your pick) you need Power9 or
> newer, so gcc135.
>
>
> Segher

Re: Expansion of narrowing math built-ins into power instructions

[Tejas Joshi]

Hello.
I have been trying to write a basic pattern taking all the suggestions
you both have mentioned. The same patch is attached here, but I cannot
see call to :

float
foo (double x, double y)
{
return __builtin_fadd (x, y);
}
being expanded to any instruction, at least a simple one, using
-fno-builtin-fadd (and also -mhard-float?). It always stays "bl fadd".
What am I missing here?

> (POWER8 and later) on.  (The result if OE=1 or UE=1 is undefined).  (See
> 4.3.5.1 in the ISA).

4.3.5.1 in the ISA says that single precision arithmetic instructions
perform operation in double format and coerces the result in single
format. Can fadd be considered as this type of instruction or do I
need to perform add in DFmode and then use "instruction provided to
explicitly convert double format operand in FPR to single format."?

Thanks,
Tejas


On Fri, 9 Aug 2019 at 04:39, Joseph Myers  wrote:
>
> On Thu, 8 Aug 2019, Segher Boessenkool wrote:
>
> > These current patterns all take the same mode for all inputs and outputs
> > (that's what 3 indicates, say, fadddf3).  You will need to define
> > something that takes two SFs in and produces a DF.  That cannot really
>
> For example, md.texi describes standard patterns such as mulhisi3 that
> multiply two HImode values and produce an SImode result (widening integer
> multiply).
>
> Using a similar naming pattern, you might have a pattern adddfsf3 that
> multiplies two DFmode values and produces an SFmode result (or you could
> call it something like add_truncdfsf3 if you wish to emphasise the
> truncation involved, for example).  Similarly addtfsf3 that multiplies
> TFmode and produces an SFmode result, and so on.  Of course these names
> need documenting (and you need corresponding RTL for them to generate that
> distinguishes the fused add+truncate from the different RTL for separate
> addition and truncation with double rounding).  In cases where long double
> and double have the same mode, the daddl function should use the existing
> adddf3 pattern.
>
> --
> Joseph S. Myers
> jos...@codesourcery.com
diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index 4ef1993..e4bfc4a 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -4652,6 +4652,21 @@
   [(set_attr "type" "fp")
(set_attr "isa" "*,")])
 
+(define_expand "add_truncdfsf3"
+  [(set (float_extend:DF (match_operand:SF 0 "gpc_reg_operand"))
+	(plus:DF (match_operand:DF 1 "gpc_reg_operand")
+		 (match_operand:DF 2 "gpc_reg_operand")))]
+  "TARGET_HARD_FLOAT"
+  "")
+
+(define_insn "*add_truncdfsf3_fpr"
+  [(set (float_extend:DF (match_operand:SF 0 "gpc_reg_operand" "="))
+	(plus:DF (match_operand:DF 1 "gpc_reg_operand" "%")
+		 (match_operand:DF 2 "gpc_reg_operand" "")))]
+  "TARGET_HARD_FLOAT"
+  "fadd %0,%1,%2"
+  [(set_attr "type" "fp")])
+
 (define_expand "sub3"
   [(set (match_operand:SFDF 0 "gpc_reg_operand")
 	(minus:SFDF (match_operand:SFDF 1 "gpc_reg_operand")
diff --git a/gcc/optabs.def b/gcc/optabs.def
index 4ffd0f3..45be794 100644
--- a/gcc/optabs.def
+++ b/gcc/optabs.def
@@ -67,6 +67,7 @@ OPTAB_CD(sfixtrunc_optab, "fix_trunc$F$b$I$a2")
 OPTAB_CD(ufixtrunc_optab, "fixuns_trunc$F$b$I$a2")
 
 /* Misc optabs that use two modes; model them as "conversions".  */
+OPTAB_CD(fadd_optab, "add_trunc$b$a3")
 OPTAB_CD(smul_widen_optab, "mul$b$a3")
 OPTAB_CD(umul_widen_optab, "umul$b$a3")
 OPTAB_CD(usmul_widen_optab, "usmul$b$a3")

Re: Expansion of narrowing math built-ins into power instructions

[Tejas Joshi]

Hi!

> As far as I understand that flag should set the behaviour of the fadd
> function, not the __builtin_fadd one.  So I don't know.

According to ISO/IEC TS 18661, I am supposed to implement the fadd
variants for folding and expand them inline, that take double and long
double as arguments and return
addition in appropriate narrower type, float and double. As far as I
know, we use __builtin_ to call the internal functions? I do not know
which the only fadd function is.

> double precision one.  But instead you want to add two double precision
> numbers, producing a single precision one?  The fadds instruction fits

Yes.

> well to that, but you'll have to check exactly how the fadd() function
> should behave with respect to rounding and exceptions and the like.

In Joseph's initial mail that describes what should be carried out in
the course of project, about rounding and exceptions. I have strictly
followed this description for my folding patch :

* 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).

Thanks,
Tejas


On Sat, 10 Aug 2019 at 22:16, Segher Boessenkool
 wrote:
>
> Hi!
>
> On Sat, Aug 10, 2019 at 04:00:53PM +0530, Tejas Joshi wrote:
> > I have been trying to write a basic pattern taking all the suggestions
> > you both have mentioned. The same patch is attached here, but I cannot
> > see call to :
> >
> > float
> > foo (double x, double y)
> > {
> > return __builtin_fadd (x, y);
> > }
> > being expanded to any instruction, at least a simple one, using
> > -fno-builtin-fadd (and also -mhard-float?). It always stays "bl fadd".
> > What am I missing here?
>
> As far as I understand that flag should set the behaviour of the fadd
> function, not the __builtin_fadd one.  So I don't know.
>
> > > (POWER8 and later) on.  (The result if OE=1 or UE=1 is undefined).  (See
> > > 4.3.5.1 in the ISA).
> >
> > 4.3.5.1 in the ISA says that single precision arithmetic instructions
> > perform operation in double format and coerces the result in single
> > format. Can fadd be considered as this type of instruction or do I
> > need to perform add in DFmode and then use "instruction provided to
> > explicitly convert double format operand in FPR to single format."?
>
> A single precision add is "fadds".  It rounds its result to single
> precision.
>
> I'm lost what the exact semantic of the wanted fadd() function are.
> I thought you wanted to add two single precision numbers, producing a
> double precision one.  But instead you want to add two double precision
> numbers, producing a single precision one?  The fadds instruction fits
> well to that, but you'll have to check exactly how the fadd() function
> should behave with respect to rounding and exceptions and the like.
>
>
> Segher

Re: Expansion of narrowing math built-ins into power instructions

[Tejas Joshi]

Hello.

> with it, but first get DP->SP (fadd) working?

Can you please review what have I have been trying and facing the
issues on patch :
<https://gcc.gnu.org/ml/gcc/2019-08/msg00078.html>

Thanks,
Tejas


On Sun, 11 Aug 2019 at 12:50, Segher Boessenkool
 wrote:
>
> Hi Tejas,
>
> On Sun, Aug 11, 2019 at 10:34:26AM +0530, Tejas Joshi wrote:
> > > As far as I understand that flag should set the behaviour of the fadd
> > > function, not the __builtin_fadd one.  So I don't know.
> >
> > According to ISO/IEC TS 18661, I am supposed to implement the fadd
> > variants for folding and expand them inline, that take double and long
> > double as arguments and return
> > addition in appropriate narrower type, float and double. As far as I
> > know, we use __builtin_ to call the internal functions? I do not know
> > which the only fadd function is.
>
> See the manual, section "Other Built-in Functions Provided by GCC":
>
>   @opindex fno-builtin
>   GCC includes built-in versions of many of the functions in the standard
>   C library.  These functions come in two forms: one whose names start with
>   the @code{__builtin_} prefix, and the other without.  Both forms have the
>   same type (including prototype), the same address (when their address is
>   taken), and the same meaning as the C library functions even if you specify
>   the @option{-fno-builtin} option @pxref{C Dialect Options}).  Many of these
>   functions are only optimized in certain cases; if they are not optimized in
>   a particular case, a call to the library function is emitted.
>
> > > double precision one.  But instead you want to add two double precision
> > > numbers, producing a single precision one?  The fadds instruction fits
> >
> > Yes.
> >
> > > well to that, but you'll have to check exactly how the fadd() function
> > > should behave with respect to rounding and exceptions and the like.
>
> I read 18661-1 now...  and yup, "fadds" will work fine, and there are
> no complications like this as far as I see.
>
> For QP to either DP or SP, you can do round-to-odd followed by one of the
> conversion instructions.  The ISA manual describes this; I can help you
> with it, but first get DP->SP (fadd) working?
>
> For the non-QP long doubles we have...  There is the option of using DP
> for it, which isn't standard-compliant, many other archs have it too,
> and it is simple anyway, because you have all code for operations
> already.  You can mostly just ignore this option.
>
> For double-double...  Well firstly, double-double is on the way out, so
> adding new features to it is pretty useless?  Just ignore it unless you
> have time left, I'd say.
>
> > In Joseph's initial mail that describes what should be carried out in
> > the course of project, about rounding and exceptions. I have strictly
> > followed this description for my folding patch :
> >
> > * 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).
>
> For Power, all five basic operations (add, sub, mul, div, fma) work fine
> wrt rounding mode if using the fadds etc. insns, for DP->SP.  All
> exceptions work as expected, except maybe underflow and overflow, but
> 18661 doesn't require much at all for those anyway :-)
>
>
> Segher

Re: Expansion of narrowing math built-ins into power instructions

[Tejas Joshi]

Hi,
I have the following code in my rs6000.md (I haven't used new TARGET_* yet) :

(define_expand "add_truncdfsf3"
  [(set (match_operand:SF 0 "gpc_reg_operand")
   (float_truncate:SF
   (plus:DF (match_operand:DF 1 "gpc_reg_operand")
(match_operand:DF 2 "gpc_reg_operand"]
  "TARGET_HARD_FLOAT"
  "")

(define_insn "*add_truncdfsf3_fpr"
  [(set (match_operand:SF 0 "gpc_reg_operand" "=f,wa")
   (float_truncate:SF
   (plus:DF (match_operand:DF 1 "gpc_reg_operand" "%d,wa")
(match_operand:DF 2 "gpc_reg_operand" "d,wa"]
  "TARGET_HARD_FLOAT"
  "@
   fadds %0,%1,%2
   xsaddsp %x0,%x1,%x2"
  [(set_attr "type" "fp")])

with following optab in optabs.def :

OPTAB_CD(fadd_optab, "add_trunc$b$a3") (what is the
difference between $b$a and $a$b?)

I have also tried adding fadd, add_truncdfsf3 in rs6000-builtin.def,
examined rtl dumps multiple times but couldn't get fadd to be
exapanded. What am I missing here?

Thanks,
Tejas

On Sun, 11 Aug 2019 at 22:29, Segher Boessenkool
 wrote:
>
> Hi Tejas,
>
> On Sat, Aug 10, 2019 at 04:00:53PM +0530, Tejas Joshi wrote:
> > +(define_expand "add_truncdfsf3"
> > +  [(set (float_extend:DF (match_operand:SF 0 "gpc_reg_operand"))
> > + (plus:DF (match_operand:DF 1 "gpc_reg_operand")
> > +  (match_operand:DF 2 "gpc_reg_operand")))]
> > +  "TARGET_HARD_FLOAT"
> > +  "")
>
> float_extend on the LHS is never correct.  I think the following should
> work, never mind that it looks like it does double rounding, because it
> doesn't (famous last words ;-) ):
>
> (define_expand "add_truncdfsf3"
>   [(set (match_operand:SF 0 "gpc_reg_operand")
> (float_truncate:SF
>   (plus:DF (match_operand:DF 1 "gpc_reg_operand")
>(match_operand:DF 2 "gpc_reg_operand"]
>   "TARGET_HARD_FLOAT"
>   "")
>
> > +(define_insn "*add_truncdfsf3_fpr"
> > +  [(set (float_extend:DF (match_operand:SF 0 "gpc_reg_operand" "="))
> > + (plus:DF (match_operand:DF 1 "gpc_reg_operand" "%")
> > +  (match_operand:DF 2 "gpc_reg_operand" "")))]
> > +  "TARGET_HARD_FLOAT"
> > +  "fadd %0,%1,%2"
> > +  [(set_attr "type" "fp")])
>
> The constraints should be "f", "%d", "d", respectively.   says to
> display something for the mode in a mode iterator.  There is no mode
> iterator here.  (In what you copied this from, there was SFDF).
>
> You want to output "fadds", not "fadd".
>
> Maybe it is easier to immediately write the VSX scalar version for this
> as well?  That's xsaddsp.  Oh, and you need to restrict all of this to
> more recent CPUs, we'll have to do some new TARGET_* flag for that I
> think.
>
> Finally: please send patches to gcc-patches@ (not gcc@).
>
> Thanks,
>
>
> Segher

Re: Expansion of narrowing math built-ins into power instructions

[Tejas Joshi]

> The RTL needs to be something that
> does *not* match the combination of separate operations (just as fma has
> its own RTL, and a separate pass is responsible for converting separate

So do I need to introduce fadd's own RTL just as fma which would emit
a fused instruction while -ffp-contract is default (fast) and would
emit separate instructions like add in DFmode and then truncate to SF?
while -ffp-contract=off ? (just as fma)


On Tue, 13 Aug 2019 at 03:22, Segher Boessenkool
 wrote:
>
> On Mon, Aug 12, 2019 at 09:20:18PM +, Joseph Myers wrote:
> > On Mon, 12 Aug 2019, Segher Boessenkool wrote:
> >
> > > (define_insn "add_truncdfsf3"
> > >   [(set (match_operand:SF 0 "gpc_reg_operand" "=f,wa")
> > > (float_truncate:SF
> > >   (plus:DF (match_operand:DF 1 "gpc_reg_operand" "%d,wa")
> > >(match_operand:DF 2 "gpc_reg_operand" "d,wa"]
> >
> > That sort of pattern is incorrect for a fused operation such as fadd,
> > because combine could match it for code that is supposed to do separate
> > addition and narrowing conversion.  The RTL needs to be something that
> > does *not* match the combination of separate operations (just as fma has
> > its own RTL, and a separate pass is responsible for converting separate
> > operations to fused ones in the -ffp-contract=fast case where it's
> > permitted).
>
> Ugh, we allow disabling contraction, I forgot.  Rats.
>
>
> Segher

Re: Expansion of narrowing math built-ins into power instructions

[Tejas Joshi]

Hello.
I just wanted to make sure that I am looking at the correct code here.
Except for rtl.def where I should be introducing something like
float_contract (or float_narrow?) and also simplify-rtx.c, breakpoints
set on functions around expr.c, cfgexpand.c where I grep for
float_truncate/FLOAT_TRUNCATE did not hit.
Also, in what manner should float_contract/narrow be different from
float_truncate as both are trying to do similar things? (truncation
from DF to SF)

Thanks,
Tejas


On Thu, 15 Aug 2019 at 02:30, Segher Boessenkool
 wrote:
>
> On Wed, Aug 14, 2019 at 08:23:27PM +, Joseph Myers wrote:
> > On Wed, 14 Aug 2019, Segher Boessenkool wrote:
> >
> > > Does something like
> > >   float d; double a, b, x;
> > >   ...
> > >   d = fadd (a + x, b - x);
> > > work as wanted, with such a representation?  It would simplify (does it?) 
> > > to
> > >   d = fadd (a, b);
> > > but is that allowed?
> >
> > It's not allowed, but neither is simplifying (a + x) + (b - x) into (a +
> > b), when contraction isn't allowed.
>
> Ah of course.  And we already should not do such simplification on RTL,
> when contraction is disallowed.
>
> So yeah it should work fine I think.  A new RTL code would be best (it
> would be silly to have to make an unspec for it in every port separately),
> but an unspec is of course easiest for now.
>
>
> Segher

Re: Expansion of narrowing math built-ins into power instructions

[Tejas Joshi]

> I think the code should instead be a fused addition and truncation,
> a bit like FMA is a fused addition and multiplication.  Describing it as
> a DFmode addition followed by some conversion to SF would still involve
> double rounding.

In that case, something like FADD. But for functions like fsub, fmul
and fdiv that does similar computation, wouldn't we need more
operation codes for them?
Is it possible to have something generalized that does *arithmetic
computation (rather than just addition)* and then *conversion
(narrowing)*? just a thought.

Thanks,
Tejas


On Thu, 15 Aug 2019 at 18:17, Richard Sandiford
 wrote:
>
> Tejas Joshi  writes:
> > Hello.
> > I just wanted to make sure that I am looking at the correct code here.
> > Except for rtl.def where I should be introducing something like
> > float_contract (or float_narrow?) and also simplify-rtx.c, breakpoints
> > set on functions around expr.c, cfgexpand.c where I grep for
> > float_truncate/FLOAT_TRUNCATE did not hit.
> > Also, in what manner should float_contract/narrow be different from
> > float_truncate as both are trying to do similar things? (truncation
> > from DF to SF)
>
> I think the code should instead be a fused addition and truncation,
> a bit like FMA is a fused addition and multiplication.  Describing it as
> a DFmode addition followed by some conversion to SF would still involve
> double rounding.
>
> simplify-rtx.c is probably the most important place to handle it.
> It would be easiest to test using the selftests at the end of the file.
>
> Thanks,
> Richard

Re: Expansion of narrowing math built-ins into power instructions

[Tejas Joshi]

Hi,

> It's just a different name, nothing more, nothing less.  Because it is
> a different name it can not be accidentally generated from actual
> truncations.

I have introduced float_narrow but I could not find appropriate places
to generate it for a call to fadd instead it to generate a CALL. I
used GDB to set breakpoints which hit fold_rtx and cse_insn but I got
confused with the rtx codes and passes which generate respective RTL.
It should not be similar to FLOAT_TRUNCATE if we want to avoid it
generating for actual truncations?

Thanks,
Tejas


On Fri, 16 Aug 2019 at 15:53, Richard Sandiford
 wrote:
>
> Segher Boessenkool  writes:
> > On Thu, Aug 15, 2019 at 01:47:47PM +0100, Richard Sandiford wrote:
> >> Tejas Joshi  writes:
> >> > Hello.
> >> > I just wanted to make sure that I am looking at the correct code here.
> >> > Except for rtl.def where I should be introducing something like
> >> > float_contract (or float_narrow?) and also simplify-rtx.c, breakpoints
> >
> > I like that "float_narrow" name :-)
> >
> >> > set on functions around expr.c, cfgexpand.c where I grep for
> >> > float_truncate/FLOAT_TRUNCATE did not hit.
> >> > Also, in what manner should float_contract/narrow be different from
> >> > float_truncate as both are trying to do similar things? (truncation
> >> > from DF to SF)
> >>
> >> I think the code should instead be a fused addition and truncation,
> >> a bit like FMA is a fused addition and multiplication.  Describing it as
> >> a DFmode addition followed by some conversion to SF would still involve
> >> double rounding.
> >
> > How so?  It would *mean* there is only single rounding, even!  That's
> > the whole point of it.
>
> But a PLUS should behave as a PLUS in any context.  Making its
> behaviour dependent on the containing rtxes (if any) would be a
> can of worms.
>
> Richard

Re: Expansion of narrowing math built-ins into power instructions

[Tejas Joshi]

> but an unspec is of course easiest for now.

So, at this point, should I proceed with UNSPEC considering the
complications that might arise as Richard points out?


On Sat, 17 Aug 2019 at 13:51, Richard Sandiford
 wrote:
>
> Tejas Joshi  writes:
> > Hi,
> >
> >> It's just a different name, nothing more, nothing less.  Because it is
> >> a different name it can not be accidentally generated from actual
> >> truncations.
> >
> > I have introduced float_narrow but I could not find appropriate places
> > to generate it for a call to fadd instead it to generate a CALL. I
> > used GDB to set breakpoints which hit fold_rtx and cse_insn but I got
> > confused with the rtx codes and passes which generate respective RTL.
> > It should not be similar to FLOAT_TRUNCATE if we want to avoid it
> > generating for actual truncations?
>
> Please don't do it this way.  The whole point of the work is that this
> is a single operation that cannot be modelled as a post-processing of
> a normal double addition result.  It's a single operation at the source
> level, a single IFN, a single optab, and a single instruction.  Splitting
> it apart into two operations for rtl only, and making it look in rtl terms
> like a post-processing of a normal addition result, seems like it's going
> to come back to bite us.
>
> In lisp terms we're saying that the operand to the float_narrow is
> implicitly quoted:
>
>   (float_narrow:m '(plus:n a b))
>
> so that when float_narrow is evaluated, the argument is the unevaluated
> rtl expression "(plus a b)" rather than the evaluated result a + b.
> float_narrow then does its own evaluation of a and b and performs a
> fused addition and narrowing on the result.
>
> No other rtx rvalue works like this.  rtx nappings like simplification
> or evaluation are normally depth-first, so that the mapping is applied
> to the operands first, and then the root is mapped/simplified/evaluated
> with the results.  Adding implicit lisp quoting would require special
> cases in these routines for float_narrow.
>
> The only current analogue I can think of for this is the handling
> of zero_extend on const_ints.  Because const_ints are modeless, we have
> to avoid cases in which the recursion produces things like:
>
>   (zero_extend:m (const_int -1))
>
> because it's no longer clear what mode the zero_extend is extending from.
> But I think that's seen as a wart of having modeless const_ints.  I don't
> think it's something we should actively embrace by adding float_narrow.
>
> Using float_narrow would also be inconsistent with the way we handle
> saturating arithmetic.  There we use US_PLUS and SS_PLUS rtx codes for
> unsigned and signed saturating plus respectively, rather than:
>
>   (unsigned_sat '(plus a b))
>   (signed_sat '(plus a b))
>
> Using dedicated codes might seem clunky.  But it's simple, safe, and fits
> the existing model without special cases. :-)
>
> Thanks,
> Richard
>
> >
> > Thanks,
> > Tejas
> >
> >
> > On Fri, 16 Aug 2019 at 15:53, Richard Sandiford
> >  wrote:
> >>
> >> Segher Boessenkool  writes:
> >> > On Thu, Aug 15, 2019 at 01:47:47PM +0100, Richard Sandiford wrote:
> >> >> Tejas Joshi  writes:
> >> >> > Hello.
> >> >> > I just wanted to make sure that I am looking at the correct code here.
> >> >> > Except for rtl.def where I should be introducing something like
> >> >> > float_contract (or float_narrow?) and also simplify-rtx.c, breakpoints
> >> >
> >> > I like that "float_narrow" name :-)
> >> >
> >> >> > set on functions around expr.c, cfgexpand.c where I grep for
> >> >> > float_truncate/FLOAT_TRUNCATE did not hit.
> >> >> > Also, in what manner should float_contract/narrow be different from
> >> >> > float_truncate as both are trying to do similar things? (truncation
> >> >> > from DF to SF)
> >> >>
> >> >> I think the code should instead be a fused addition and truncation,
> >> >> a bit like FMA is a fused addition and multiplication.  Describing it as
> >> >> a DFmode addition followed by some conversion to SF would still involve
> >> >> double rounding.
> >> >
> >> > How so?  It would *mean* there is only single rounding, even!  That's
> >> > the whole point of it.
> >>
> >> But a PLUS should behave as a PLUS in any context.  Making its
> >> behaviour dependent on the containing rtxes (if any) would be a
> >> can of worms.
> >>
> >> Richard

[GSoC-19] Expanding fromfp variants on AArch64

[Tejas Joshi]

Hello.
The fromfp/fromfpx variants round to integers with a specified number
of bits, to a specified rounding mode. They come with their own
complications as Joseph had stated in an initial mail and expected to
expand them in AArch64 :

> The fromfp / fromfpx / ufromfp / ufromfpx functions (round to integers
> of a specified number of bits, in a specified rounding mode, with
> specified handling of inexact results) are a case with some other
> complications.  Typically I'd expect them to be expanded inline only (for
> constant arguments or) for constant values of the number of bits and
> rounding mode, if the target machine has an appropriate instruction.  A
> target hook would need adding for a target to specify the FP_INT_* values
> used in libm, since that's an ABI that's defined by libm, not by GCC.
> Then you'd need instruction patterns that might only be supported in
> certain cases.

How can I add a target hook to specify the FP_INT_* values from libm ?
Also as this includes rounding to integers, does it involve any RTL
related complications that we have encountered in FADD ?

Thanks,
Tejas

[GSoC-19] Final Evaluations

[Tejas Joshi]

Hello.
The deadline for final evaluations is 26th of August and there are
certain things that I need to submit along with the code.
A link has to be submitted of the codes that I have written and I am
thinking of doing it as a github gist along with links to commits to
my gcc fork. I know that the documentation in the respective .texi
files is still remaining, of whatever changes I have made and I will
do it as soon as I can but I have to give some of my time to
university exams from 20th to 24th of this month.
I also need to mention the codes that have been merged with the
original source code of GCC. I don't know what codes are OK to be
merged with GCC.
Patches I have submitted till now :





Other things like FADD variants expansion and fromfp variants
expansion that needed to be completed in the course of GSoC is
remaining and I am trying my best to complete it till the end of
deadline. Even if some work remains, I will continue to work on them
to completion and also want to extend my work with other intricacies
or works, even in the ISO/IEC specifications/extensions.

Thanks,
Tejas

Re: Expansion of narrowing math built-ins into power instructions

[Tejas Joshi]

Hello.
I have the following code which uses unspec but I am really missing
something here. Does unspec not work encapsulating plus? Or I have
some more places to make changes to?

(define_insn "add_truncdfsf3"
  [(set (match_operand:SF 0 "gpc_reg_operand" "=,wa")
   (unspec:SF
   [(plus:DF (match_operand:DF 1 "gpc_reg_operand" "%,wa")
 (match_operand:DF 2 "gpc_reg_operand" ",wa"))]
  UNSPEC_ADD_TRUNCATE))]
  "TARGET_HARD_FLOAT"
  "@
   fadds %0,%1,%2
   xsaddsp %x0,%x1,%x2"
  [(set_attr "type" "fp")])

and an UNSPEC_ADD_TRUNCATE in unspec enum.

Thanks,
Tejas

On Wed, 21 Aug 2019 at 01:12, Segher Boessenkool
 wrote:
>
> On Tue, Aug 20, 2019 at 03:43:43PM +0100, Richard Sandiford wrote:
> > Segher Boessenkool  writes:
> > > On Tue, Aug 20, 2019 at 01:59:06PM +0100, Richard Sandiford wrote:
> > >> Segher Boessenkool  writes:
> > >> >>   [(set (match_operand:SI 0 "register_operand" "=d")
> > >> >> (truncate:SI
> > >> >>  (lshiftrt:DI
> > >> >
> > >> > (this is optimised to a subreg, in many cases, for example).
> > >>
> > >> Right.  MIPS avoids that one thanks to TARGET_TRULY_NOOP_TRUNCATION.
> > >
> > > Trying 10 -> 18:
> > >10: r200:TI=zero_extend(r204:DI)*zero_extend(r205:DI)
> > >   REG_DEAD r205:DI
> > >   REG_DEAD r204:DI
> > >18: $2:DI=r200:TI#0
> > >   REG_DEAD r200:TI
> > > Failed to match this instruction:
> > > (set (reg/i:DI 2 $2)
> > > (subreg:DI (mult:TI (zero_extend:TI (reg:DI 204))
> > > (zero_extend:TI (reg:DI 205))) 0))
> > >
> > > I'm afraid not.
> >
> > That's TI->DI though, whereas the pattern above is DI->SI.  The modes
> > matter :-)  There'd also need to be a shift to match a highpart pattern.
>
> It's the same for 32-bit:
>
> mips-linux-gcc -Wall -W -O2 -S mulh.c -mips32 -mabi=32
> (I hope these options are reasonable?  I don't know MIPS well at all).
>
> Trying 12 -> 20:
>12: r200:DI=zero_extend(r204:SI)*zero_extend(r205:SI)
>   REG_DEAD r205:SI
>   REG_DEAD r204:SI
>20: $2:SI=r200:DI#0
>   REG_DEAD r200:DI
> Failed to match this instruction:
> (set (reg/i:SI 2 $2)
> (subreg:SI (mult:DI (zero_extend:DI (reg:SI 204))
> (zero_extend:DI (reg:SI 205))) 0))
>
> The point is that this is the form that this insn is simplified to.  If
> that form is not recognised by your backend, various optimisation
> opportunities are missed.
>
> > I wouldn't say it knows nothing about rounding.  It doesn't know
> > what the runtime rounding mode is, but that isn't the same thing.
> > (Just like not knowing what (mem:SI (sp)) contains isn't the same
> > thing as not knowing anything about stack memory.)
>
> Does it even know if the rounding mode is one of the IEEE FP rounding
> modes?
>
>
> Segher

Re: Expansion of narrowing math built-ins into power instructions

[Tejas Joshi]

> This does almost exactly the same as what the proposed float_narrow
> would do.  Instead, write it as
>
> (define_insn "add_truncdfsf3"
>   [(set (match_operand:SF 0 "gpc_reg_operand" "=,wa")
> (unspec:SF [(match_operand:DF 1 "gpc_reg_operand" "%,wa")
> (match_operand:DF 2 "gpc_reg_operand" ",wa")]
>UNSPEC_ADD_TRUNCATE)]
>   "TARGET_HARD_FLOAT"
>   "@
>fadds %0,%1,%2
>xsaddsp %x0,%x1,%x2"
>   [(set_attr "type" "fp")
>(set_attr "isa" "*,p8v")])

Yes, I tried basically every combination I could think of, just not
with the "isa attr". Now, I have the following code and it is still
seems not to be working. Am I missing any options to pass?

(define_insn "add_truncdfsf3"
  [(set (match_operand:SF 0 "gpc_reg_operand" "=f,wa")
  (unspec:SF [(match_operand:DF 1 "gpc_reg_operand" "%d,wa")
 (match_operand:DF 2 "gpc_reg_operand" "d,wa")]
  UNSPEC_ADD_NARROWING))]
  "TARGET_HARD_FLOAT"
  "@
   fadds %0,%1,%2
   xsaddsp %x0,%x1,%x2"
  [(set_attr "type" "fp")
   (set_attr "isa" "*,p8v")])

with the code, I pass -O2 foo.c :
float
foo (double x, double y)
{
   return __builtin_fadd (x, y);
}

Thanks,
Tejas


On Thu, 22 Aug 2019 at 00:47, Segher Boessenkool
 wrote:
>
> On Wed, Aug 21, 2019 at 01:28:52PM -0500, Segher Boessenkool wrote:
> > (define_insn "add_truncdfsf3"
> >   [(set (match_operand:SF 0 "gpc_reg_operand" "=,wa")
> >   (unspec:SF [(match_operand:DF 1 "gpc_reg_operand" "%,wa")
> >   (match_operand:DF 2 "gpc_reg_operand" ",wa")]
> >  UNSPEC_ADD_TRUNCATE)]
> >   "TARGET_HARD_FLOAT"
> >   "@
> >fadds %0,%1,%2
> >xsaddsp %x0,%x1,%x2"
> >   [(set_attr "type" "fp")
> >(set_attr "isa" "*,p8v")])
>
> And not ...  f, d, d respectively (f for SF, d for DF).
>
>
> Segher

Re: Expansion of narrowing math built-ins into power instructions

[Tejas Joshi]

> What happens then?  "It does not work" is very very vague.  At least it
> seems the compiler does build now?

Oh, compiler builds but instruction is still "bl fadd". It should be
"fadds" right?


On Thu, 22 Aug 2019 at 11:55, Segher Boessenkool
 wrote:
>
> Hi Tejas,
>
> [ Please do not top-post. ]
>
> On Thu, Aug 22, 2019 at 09:09:37AM +0530, Tejas Joshi wrote:
> > Yes, I tried basically every combination I could think of, just not
> > with the "isa attr". Now, I have the following code and it is still
> > seems not to be working. Am I missing any options to pass?
> >
> > (define_insn "add_truncdfsf3"
> >   [(set (match_operand:SF 0 "gpc_reg_operand" "=f,wa")
> >   (unspec:SF [(match_operand:DF 1 "gpc_reg_operand" "%d,wa")
> >  (match_operand:DF 2 "gpc_reg_operand" "d,wa")]
> >   UNSPEC_ADD_NARROWING))]
> >   "TARGET_HARD_FLOAT"
> >   "@
> >fadds %0,%1,%2
> >xsaddsp %x0,%x1,%x2"
> >   [(set_attr "type" "fp")
> >(set_attr "isa" "*,p8v")])
> >
> > with the code, I pass -O2 foo.c :
> > float
> > foo (double x, double y)
> > {
> >return __builtin_fadd (x, y);
> > }
>
> What happens then?  "It does not work" is very very vague.  At least it
> seems the compiler does build now?
>
>
> Segher

Re: [PATCH] Builtin function roundeven folding implementation

[Tejas Joshi]

> I'm concerned that this would produce +0.0 for an argument of -0.5 (via
> -0.5 - 0.5 - -1.0 producing +0.0) when it needs to produce -0.0.

Would the following overhaul be acceptable as the condition is
specialized for -0.5 and +0.5 only. This seems to solve the problem. I
did test the roundeven tests and it passes the tests.

void
real_roundeven (REAL_VALUE_TYPE *r, format_helper fmt,
const REAL_VALUE_TYPE *x)
{
  if (is_halfway_below (x))
  {
if (REAL_EXP (x) == 0)
{
  *r = *x;
  clear_significand_below (r, SIGNIFICAND_BITS);
}
else
{
  do_add (r, x, &dconsthalf, x->sign);
  if (!is_even (r))
do_add (r, r, &dconstm1, x->sign);
}
if (fmt)
  real_convert (r, fmt, r);
  }
  else
real_round (r, fmt, x);
}

tests:

/* { dg-do link } */

extern int link_error (int);

#define TEST(FN, VALUE, RESULT) \
  if (__builtin_##FN (VALUE) != RESULT) link_error (__LINE__);

int
main (void)
{
  TEST(roundeven,  0, 0);
  TEST(roundeven,  0.5, 0);
  TEST(roundeven,  -0.5, 0);
  TEST(roundeven,  6, 6);
  TEST(roundeven,  -8, -8);
  TEST(roundeven,  2.5, 2);
  TEST(roundeven,  3.5, 4);
  TEST(roundeven,  -1.5, -2);
  TEST(roundeven,  3.499, 3);
  TEST(roundeven,  3.501, 4);

  if (__builtin_copysign (1, __builtin_roundeven (-0.5)) != -1)
link_error (__LINE__);
  return 0;
}

Thanks,
Tejas



On Thu, 22 Aug 2019 at 20:03, Joseph Myers  wrote:
>
> On Thu, 22 Aug 2019, Martin Jambor wrote:
>
> > +/* Round X to nearest integer, rounding halfway cases towards even.  */
> > +
> > +void
> > +real_roundeven (REAL_VALUE_TYPE *r, format_helper fmt,
> > + const REAL_VALUE_TYPE *x)
> > +{
> > +  if (is_halfway_below (x))
> > +  {
> > +do_add (r, x, &dconsthalf, x->sign);
> > +if (!is_even (r))
> > +  do_add (r, r, &dconstm1, x->sign);
>
> I'm concerned that this would produce +0.0 for an argument of -0.5 (via
> -0.5 - 0.5 - -1.0 producing +0.0) when it needs to produce -0.0.
>
> Note that testcases for the sign of zero results need to check e.g.
> !!__builtin_signbit on the result, or the result of calling
> __builtin_copysign* to extract the sign of the result, since 0.0 == -0.0
> so checking with ==, while necessary, is not sufficient in that case.
>
> --
> Joseph S. Myers
> jos...@codesourcery.com

Re: [PATCH] Builtin function roundeven folding implementation

[Tejas Joshi]

> I think you should have at least four tests of sign of zero result
> (arguments -0.5, -0.0, 0.0 and 0.5).  Probably also tests of values
> between +/- 0.5 and 0, e.g. test -0.25 and 0.25 as well.

Okay, I have made the following changes and again, the tests pass for roundeven.

void
real_roundeven (REAL_VALUE_TYPE *r, format_helper fmt,
const REAL_VALUE_TYPE *x)
{
  if (is_halfway_below (x))
  {
/* Special case as -0.5 rounds to -0.0 and
   similarly +0.5 rounds to +0.0.  */
if (REAL_EXP (x) == 0)
{
  *r = *x;
  clear_significand_below (r, SIGNIFICAND_BITS);
}
else
{
  do_add (r, x, &dconsthalf, x->sign);
  if (!is_even (r))
do_add (r, r, &dconstm1, x->sign);
}
if (fmt)
  real_convert (r, fmt, r);
  }
  else
real_round (r, fmt, x);
}

Tests :

/* { dg-do link } */

extern int link_error (int);

#define TEST(FN, VALUE, RESULT) \
  if (__builtin_##FN (VALUE) != RESULT) link_error (__LINE__);

int
main (void)
{
  TEST(roundeven,  0, 0);
  TEST(roundeven,  0.5, 0);
  TEST(roundeven,  -0.5, 0);
  TEST(roundeven,  6, 6);
  TEST(roundeven,  -8, -8);
  TEST(roundeven,  2.5, 2);
  TEST(roundeven,  3.5, 4);
  TEST(roundeven,  -1.5, -2);
  TEST(roundeven,  3.499, 3);
  TEST(roundeven,  3.501, 4);

  if (__builtin_copysign (1, __builtin_roundeven (-0.5)) != -1)
link_error (__LINE__);
  if (__builtin_copysign (1, __builtin_roundeven (-0.0)) != -1)
link_error (__LINE__);
  if (__builtin_copysign (-1, __builtin_roundeven (0.5)) != 1)
link_error (__LINE__);
  if (__builtin_copysign (-1, __builtin_roundeven (0.0)) != 1)
link_error (__LINE__);
  if (__builtin_copysign (1, __builtin_roundeven (-0.25)) != -1)
link_error (__LINE__);
  if (__builtin_copysign (-1, __builtin_roundeven (0.25)) != 1)
link_error (__LINE__);
  return 0;
}

Thanks,
Tejas


On Thu, 22 Aug 2019 at 22:05, Joseph Myers  wrote:
>
> On Thu, 22 Aug 2019, Tejas Joshi wrote:
>
> > > I'm concerned that this would produce +0.0 for an argument of -0.5 (via
> > > -0.5 - 0.5 - -1.0 producing +0.0) when it needs to produce -0.0.
> >
> > Would the following overhaul be acceptable as the condition is
> > specialized for -0.5 and +0.5 only. This seems to solve the problem. I
> > did test the roundeven tests and it passes the tests.
>
> I think that would be reasonable with a comment added to explain that it's
> ensuring the correct sign of a zero result.
>
> >   if (__builtin_copysign (1, __builtin_roundeven (-0.5)) != -1)
> > link_error (__LINE__);
>
> I think you should have at least four tests of sign of zero result
> (arguments -0.5, -0.0, 0.0 and 0.5).  Probably also tests of values
> between +/- 0.5 and 0, e.g. test -0.25 and 0.25 as well.
>
> --
> Joseph S. Myers
> jos...@codesourcery.com

Re: [PATCH] Builtin function roundeven folding implementation

[Tejas Joshi]

I have made the respective changes and fixed the indentations and it
passes the testing.

> I encourage a followup looking for and fixing further places in the source
> tree that handle round-to-integer function families (ceil / floor / trunc
> / round / rint / nearbyint) and should handle roundeven as well, as that
> would lead to more optimization of roundeven calls.  Such places aren't
> that easy to search for because most of those names are common words used
> in other contexts in the compiler.  But, for example, match.pd has
> patterns

I will follow up to make these optimizations for sure.

Thanks,
Tejas


On Sat, 24 Aug 2019 at 02:08, Joseph Myers  wrote:
>
> On Fri, 23 Aug 2019, Tejas Joshi wrote:
>
> > diff --git a/gcc/builtins.c b/gcc/builtins.c
> > index 9a766e4ad63..5149d901a96 100644
> > --- a/gcc/builtins.c
> > +++ b/gcc/builtins.c
> > @@ -2056,6 +2056,7 @@ mathfn_built_in_2 (tree type, combined_fn fn)
> >  CASE_MATHFN (REMQUO)
> >  CASE_MATHFN_FLOATN (RINT)
> >  CASE_MATHFN_FLOATN (ROUND)
> > +CASE_MATHFN (ROUNDEVEN)
>
> This should use CASE_MATHFN_FLOATN, as for the other round-to-integer
> functions.
>
> > +  /* Check lowest bit, if not set, return true.  */
> > +  else if (REAL_EXP (r) <= SIGNIFICAND_BITS)
> > +  {
> > +unsigned int n = SIGNIFICAND_BITS - REAL_EXP (r);
> > +int w = n / HOST_BITS_PER_LONG;
> > +
> > +unsigned long num = ((unsigned long)1 << (n % HOST_BITS_PER_LONG));
> > +
> > +if ((r->sig[w] & num) == 0)
> > +  return true;
>
> Fix the indentation here (the braces should be indented two columns from
> the "else", the contents then two columns from the braces).
>
> > +  }
> > +
> > +  else
>
> And remove the stray blank line before "else".
>
> > +/* Return true if R is halfway between two integers, else return
> > +   false.  The function is not valid for rvc_inf and rvc_nan classes.  */
> > +
> > +bool
> > +is_halfway_below (const REAL_VALUE_TYPE *r)
> > +{
> > +  gcc_assert (r->cl != rvc_inf);
> > +  gcc_assert (r->cl != rvc_nan);
> > +  int i;
>
> Explicitly check for rvc_zero and return false in that case (that seems to
> be the convention in real.c, rather than relying on code using REAL_EXP to
> do something sensible for zero, which has REAL_EXP of 0).
>
> > +  else if (REAL_EXP (r) < SIGNIFICAND_BITS)
> > +  {
>
> Another place to fix indentation.
>
> > +void
> > +real_roundeven (REAL_VALUE_TYPE *r, format_helper fmt,
> > + const REAL_VALUE_TYPE *x)
> > +{
> > +  if (is_halfway_below (x))
> > +  {
>
> Again, fix indentation throughout this function.
>
> The patch is OK with those fixes, assuming the fixed patch passes testing.
> I encourage a followup looking for and fixing further places in the source
> tree that handle round-to-integer function families (ceil / floor / trunc
> / round / rint / nearbyint) and should handle roundeven as well, as that
> would lead to more optimization of roundeven calls.  Such places aren't
> that easy to search for because most of those names are common words used
> in other contexts in the compiler.  But, for example, match.pd has
> patterns
>
> /* trunc(trunc(x)) -> trunc(x), etc.  */
>
> /* f(x) -> x if x is integer valued and f does nothing for such values.  */
>
>  /* truncl(extend(x)) -> extend(trunc(x)), etc., if x is a double.  */
>
>  /* truncl(extend(x)) and trunc(extend(x)) -> extend(truncf(x)), etc.,
> if x is a float.  */
>
> which should apply to roundeven as well.
>
> --
> Joseph S. Myers
> jos...@codesourcery.com

Re: Expansion of narrowing math built-ins into power instructions

[Tejas Joshi]

Hello.
>
> Similarly addtfsf3 that multiplies TFmode and produces an SFmode result, and 
> so on.

I want to extend this patch for FADDL and DADDL. What operand
constraints should I use for TFmode alongside "f"?

> In cases where long double and double have the same mode,
>the daddl function should use the existing adddf3 pattern.

So, should I use adddf3 for DADDL directly? How would I map the
add3 optab with DADDL?

Thanks,
Tejas


On Sat, 24 Aug 2019 at 15:23, Richard Sandiford
 wrote:
>
> Martin Jambor  writes:
> > Hello,
> >
> > On Thu, Aug 22 2019, Segher Boessenkool wrote:
> >>> > Hi Tejas,
> >>> >
> >>> > [ Please do not top-post. ]
> >>
> >> On Thu, Aug 22, 2019 at 01:27:06PM +0530, Tejas Joshi wrote:
> >>> > What happens then?  "It does not work" is very very vague.  At least it
> >>> > seems the compiler does build now?
> >>>
> >>> Oh, compiler builds but instruction is still "bl fadd". It should be
> >>> "fadds" right?
> >>
> >> Yes, but that means the problem is earlier, before it hits RTL perhaps.
> >>
> >> Compile with -dap, look at the expand dump (the lowest numbered one, 234
> >> or so), and see what it looked like in the final Gimple, and then in the
> >> RTL generated from that.  And then drill down.
> >>
> >
> > Tejas sent me his patch and I looked at why it did not work.  I found
> > two reasons:
> >
> > 1. associated_internal_fn (in builtins.c) does not handle
> >DEF_INTERNAL_OPTAB_FN kind of internal functions, and Tejas
> >(sensibly, I'd say) used that macro to define the internal function.
> >But when I worked around that by manually adding a case for it in the
> >switch statement, I ran into an assert because...
> >
> > 2. direct_internal_fn_supported_p on which replacement_internal_fn
> >depends to expand built-ins as internal functions cannot handle
> >conversion optabs... and narrowing is a kind of conversion and the
> >optab is added as such with OPTAB_CD.
> >
> > Actually, the second statement is not entirely true because somehow it
> > can handle optab while_ult which is a conversion optab but a) the way it
> > is handled, if I can understand it at all, seems to be a big hack and
> > would be even worse if we decided to copy that for all narrowing math
> > functions
>
> Think "big hack" is a bit unfair.  The way that the internal function
> maps argument types to the optab modes, and the way it expands calls
> into rtl, depends on the "optab type" argument (the final argument to
> DEF_INTERNAL_OPTAB_FN).  This is relatively flexible in that it can use
> a single-mode "direct" optab or a dual-mode "conversion" optab, with the
> modes coming from whichever arguments are appropriate.  New optab types
> can be added as needed.
>
> FWIW, several other DEF_INTERNAL_OPTAB_FNs are conversion optabs too
> (e.g. IFN_LOAD_LANES, IFN_STORE_LANES, IFN_MASK_LOAD, etc.).
>
> But...
>
> > and b) it gets both modes from argument types whereas we need one from
> > the result type and so we would have to rewrite
> > replacement_internal_fn anyway.
>
> ...yeah, I agree this breaks the current model.  The reason IFN_WHILE_ULT
> doesn't rely on the return type is that if you have:
>
>   _2 = .WHILE_ULT (_0, _1) // returning a vector of 4 booleans
>   _3 = .WHILE_ULT (_0, _1) // returning a vector of 8 booleans
>
> then the calls look equivalent.  So instead we pass an extra argument
> indicating the required boolean vector "shape".
>
> The same "problem" could in principle apply to FADD if we ever needed
> to support double+double->_Float16 for example.
>
> > Therefore, at least for now (GSoC deadline is kind of looming), I
> > decided that the best way forward would be to not rely on internal
> > functions but plug into expand_builtin() and I wrote the following,
> > lightly tested patch - which of course misses testcases and stuff - but
> > I'd be curious about any feedback now anyway.  When I proposed a very
> > similar approach for the roundeven x86_64 expansion, Uros actually then
> > opted for a solution based on internal functions, so I am curious
> > whether there are simple alternatives I do not see.
> >
> > Tejas, of course cases for other fadd variants should at least be added
> > to expand_builtin.
> >
> > Thanks,
> >
> > Martin
> >
> >
> > 2019-08-23  Tejas Joshi  
> >   Martin

Re: Expansion of narrowing math built-ins into power instructions

[Tejas Joshi]

Hello.
Sorry for not being clear. I am confused about some modes here. I
meant, just as we expanded fadd (which narrows down from double to
float) with add_truncdfsf3, how can I expand faddl (which narrows down
long double to float). Wouldn't I require TFmode -> SFmode as
add_trunctfsf3 just as Joseph had previously mentioned? And if yes,
the operand constraints would still be f,d and d for TF->SF or what?
Also, just as we generated fadds/xsaddsp instructions for fadd, would
I be generating the same ones for faddl and fadd/xsadddp for daddl
(long double to double) or something different? all for ISA 2.07. (for
ISA 3.0, I might use IEEE128/FLOAT128 round-to-odd instructions like
add_odd followed by conversion to narrower?)

Thanks,
Tejas

On Sun, 25 Aug 2019 at 22:17, Segher Boessenkool
 wrote:
>
> [ Please don't top-post ]
>
> On Sun, Aug 25, 2019 at 07:32:01PM +0530, Tejas Joshi wrote:
> > I want to extend this patch for FADDL and DADDL. What operand
> > constraints should I use for TFmode alongside "f"?
>
> It depends on the instruction you use, and what registers that then
> works on.  GPRs get "r", FPRs get "f" for SFmode but "d" otherwise, the
> VRs get "v", if all VSRs are allowed you get "wa".  And there are some
> mode attributes to go with mode iterators for when you handle multiple
> modes (which you always do, you need to handle KF as well).
>
> What machine insns do you want to generate?  There most likely is
> something a lot like it already, so take that as example?
>
> > > In cases where long double and double have the same mode,
> > >the daddl function should use the existing adddf3 pattern.
>
> Sure, that probably should be handled in generic code (not rs6000).
> Where it would generate an adddfdf2 it should just do an adddf3.
>
> > So, should I use adddf3 for DADDL directly? How would I map the
> > add3 optab with DADDL?
>
> Simply check if source and target mode are the same?
>
>
> Segher

[GSoC-19] Adding functions in math.h as built-ins

[Tejas Joshi]

Hello.
As deadline of GSoC has ended and regardless of what it results into,
I would like to sincerely thanks GCC for giving me this opportunity to
contribute in and learn GCC which helped me to get to know open source
community.
Working on this project has helped me to not only elevate my knowledge
about GCC, its intrinsic but also compilers in general, C, C++ and
floating point intrinsics too and will definitely assist me in
developing my future career and opportunities.
I would like to thanks Martin and Honza for guiding me throughout this
course of project and also all those people, especially Joseph, Segher
and Richard who actively assisted me for the problems I encountered.
Although the project hasn't met its specified deliverables till
deadline, I will still continue to work on the remaining things so
that those get comitted too and will keep seeking for inputs whenever
I need.

Thanks,
Tejas

Re: Expansion of narrowing math built-ins into power instructions

[Tejas Joshi]

Hello.

> For ISA 2.07 (Power 8) you don't have IEEE128 at all, not in hardware
> that is.  I don't know if we'll want fadd support in the emulation
> libraries ever; don't worry about it for now, anyway.

What instructions would need to be expanded for FADDL (long double to
float) and DADDL (long double to double) on power8 (ISA 2.07) and
power9 (ISA 3.0) respectively, along with VSX? (Just as we expanded
FADD to fadds and xsaddsp for vsx).

Thanks,
Tejas


On Mon, 26 Aug 2019 at 13:12, Segher Boessenkool
 wrote:
>
> > > [ Please don't top-post ]
>
> On Mon, Aug 26, 2019 at 12:43:44PM +0530, Tejas Joshi wrote:
> > Sorry for not being clear. I am confused about some modes here. I
> > meant, just as we expanded fadd (which narrows down from double to
> > float) with add_truncdfsf3, how can I expand faddl (which narrows down
> > long double to float). Wouldn't I require TFmode -> SFmode as
> > add_trunctfsf3 just as Joseph had previously mentioned?
>
> Yes, you need an addsfkf2 as well as adddfkf2 (and tf variants of those,
> there are iterators for that).
>
> KF is IEEE QP float.  TF is whatever long double maps to, IEEE QP or
> double-double.
>
> > And if yes,
> > the operand constraints would still be f,d and d for TF->SF or what?
>
> SF is "f".  KF does not fit in "d".
>
> You won't need constraints anyway.  There already is add3_odd and
> you can just use that, in a new defione_expand you make.  For example,
> for DP you need two insns: xsaddqpo followed by xscvqpdp.  The second
> of those is the existing insn pattern truncdf2_hw, so you just get
> something like
>
> (define_expand "adddfkf2"
>   [(set (match_operand:DF 0 "gpc_reg_operand")
> (unspec:DF [(match_operand:IEEE128 1 "gpc_reg_operand")
> (match_operand:IEEE128 2 "gpc_reg_operand")]
>UNSPEC_DUNNO_MENTION_DF_SOMEHOW))]
>   "TARGET_FLOAT128_HW && FLOAT128_IEEE_P (mode)"
> {
>   rtx tmp = gen_reg_rtx (mode);
>   emit_insn (gen_add3_odd (tmp, operands[1], operands[2]);
>   emit_insn (truncdf2_hw (operands[0], tmp));
>   DONE;
> })
>
> (not tested at all, be careful :-) )
>
> > Also, just as we generated fadds/xsaddsp instructions for fadd, would
> > I be generating the same ones for faddl and fadd/xsadddp for daddl
> > (long double to double) or something different? all for ISA 2.07. (for
> > ISA 3.0, I might use IEEE128/FLOAT128 round-to-odd instructions like
> > add_odd followed by conversion to narrower?)
>
> For ISA 2.07 (Power 8) you don't have IEEE128 at all, not in hardware
> that is.  I don't know if we'll want fadd support in the emulation
> libraries ever; don't worry about it for now, anyway.
>
> "long double is double" you should probably handle in generic code.
> "long double is double-double", well, fadd cannot really be done better
> than an add followed by a conversion in that case?  Which boils down
> to truncating the inputs to double, and then doing whatever you would
> do for IEEE DP float.
>
>
> Segher

Re: Expansion of narrowing math built-ins into power instructions

[Tejas Joshi]

On Sat, 31 Aug 2019 at 02:05, Segher Boessenkool
 wrote:
>
> > > > > [ Please don't top-post ]
>
> (I delete everything under your signature, without looking, assuming you
> just forgot to).

Oh sorry, I didn't know the reply button does evil things. :-)

> If long double is double, faddl is the same as fadd, and daddl is just
> normal addition.
>
> If long double is double-double, faddl can be done as fadd on the first
> double precision component of both args, and daddl is just normal addition
> of those.
>
> If long double is IEEE QP, then it is more interesting :-)

On what conditions does the mapping of long double to double/
double-double or IEEE QP changes or depends, so that I can test it.

Thanks,
Tejas

GSoC

[Tejas Joshi]

"GCC supports built-in functions for math.h and complex.h functions in
the C99/C11 standards (both folding calls for constant arguments, and
expanding inline when the processor supports appropriate
functionality). More such functions have been added in ISO/IEC TS
18661, supporting features of IEEE 754-2008. It would be useful to
have built-in functions for those, both folding for constant
arguments, and expanding inline where appropriate (e.g. for roundeven
and the functions rounding result to narrower type, on some
processors; roundeven can be inlined on x86 for SSE4.1 and later, and
the narrowing functions on IA64 and POWER8, for example)".

The above Project Idea is made available on 'Summer of Code' wiki of
GNU GCC Website. I wanted to have some more details about above idea
regarding to what is expected for implementation and expected output
for the same.

-Tejas Joshi

Further for GSoC.

[Tejas Joshi]

>
> > The above Project Idea is made available on 'Summer of Code' wiki of
> > GNU GCC Website. I wanted to have some more details about above idea
> > regarding to what is expected for implementation and expected output
> > for the same.


I've been having interest in this idea I already asked about but forgot to
introduce myself.

I, Tejas Joshi, studying undergraduate Computer Engineering, Pune
University, India.
I've worked and still working in interested C,C++ and always had keen
interest in Languages and processing. I am a member of team, which has been
selected for Smart India hackathon 2018. Working for math.h and complex.h
functions is really interesting and want to apply for it.

First of all, thanking you Sir Myers for immediate and elaborated response.
As far as I think for now, the approach for the problem would be(shortly):

1. There are in-built functions present for ceil / floor / etc. I am
suppose to add functions in which existing ones get folded for constant
arguments.

2. Expanding them inline for non-constant arguments depending upon target
processor and implementing new instruction patterns.

Just as Sir said.
I have some university level experience of working and programming assembly
language under Intel 80386DX architecture. I think it may help for
implementing supports for other architectures. Just for start, you
mentioned roundeven function as a guide for start. Where can I find these
(e.g. real.c) .c files for detailed study of these functions so that I can
have broader scenario? I have GCC 7.2.0 installed and could not find it in
library nor in libc/.

-Tejas Joshi.

Re: Further for GSoC.

[Tejas Joshi]

 On 6 March 2018 at 22:25, Martin Jambor wrote:

> > You might have figured this out already but just in case something is
> > not clear:
> >
> >   1. How to check out our sources using svn and git is described at
> > https://gcc.gnu.org/svn.html and https://gcc.gnu.org/wiki/GitMirror
> > respectively, and
> >
> >   2. perhaps more importantly, how to configure, build and test GCC is
> > described in steps linked from https://gcc.gnu.org/install/ (look
> > for --disable-bootstrap, among other things).
>
> Or start with at https://gcc.gnu.org/wiki/InstallingGCC and
>
>> https://gcc.gnu.org/wiki/GettingStarted
>
> You need to check out the GCC source code from version control and find
the files and functions referenced in there (locating pieces of GCC code
using find, grep, etc. on the GCC source tree is something you'll need to
do a lot), and make sure you can build GCC, run the testsuite, save
results from a testsuite run, build and run the testsuite and compare the
results of the two runs (this is something that would need doing very many
times in the course of any project working on GCC).


Thank you all of you for your suggestions.
Was not mailing for some days because caught up in exams.
Interested in this project and working on it.
Thank you.

-Tejas



On 7 March 2018 at 18:05, Jonathan Wakely  wrote:

> On 6 March 2018 at 22:25, Martin Jambor wrote:
> > You might have figured this out already but just in case something is
> > not clear:
> >
> >   1. How to check out our sources using svn and git is described at
> > https://gcc.gnu.org/svn.html and https://gcc.gnu.org/wiki/GitMirror
> > respectively, and
> >
> >   2. perhaps more importantly, how to configure, build and test GCC is
> > described in steps linked from https://gcc.gnu.org/install/ (look
> > for --disable-bootstrap, among other things).
>
> Or start with at https://gcc.gnu.org/wiki/InstallingGCC and
> https://gcc.gnu.org/wiki/GettingStarted
>

GSoC 2018 - Adding functions in math.h

[Tejas Joshi]

> * roundeven is similar to existing functions round / ceil / floor / trunc.
> So you'd define built-in functions (roundeven / roundevenf / roundevenl
> and _FloatN and _FloatNx variants) similar to those for the older rounding
> functions, in builtins.def.



Hello,
Thanks to all for your inputs to get me through. As mentioned above, I
have added the function roundeven in match.pd
and its declaration in builtins.def for the testcase 0. Following is the
attachment patch for the same.

For inlining functions, is it the same kind of specialized expansion from
GIMPLE to RTL which is already there for some math functions in bultins.c?
If I get more clear with it, I'd get to go for the proposal.
Thank you.


Regards,
-Tejas

Patch Attachment:
diff --git a/gcc/builtins.def b/gcc/builtins.def
index 17f825da367..70640a53347 100644
--- a/gcc/builtins.def
+++ b/gcc/builtins.def
@@ -563,6 +563,7 @@ DEF_C99_BUILTIN(BUILT_IN_RINTL, "rintl", BT_FN_LONGDOUBLE_LONGDOUBLE, AT
 DEF_EXT_LIB_FLOATN_NX_BUILTINS (BUILT_IN_RINT, "rint", RINT_TYPE, ATTR_CONST_NOTHROW_LEAF_LIST)
 #undef RINT_TYPE
 DEF_C99_BUILTIN(BUILT_IN_ROUND, "round", BT_FN_DOUBLE_DOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
+DEF_C11_BUILTIN(BUILT_IN_ROUNDEVEN, "roundeven", BT_FN_DOUBLE_DOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_C99_BUILTIN(BUILT_IN_ROUNDF, "roundf", BT_FN_FLOAT_FLOAT, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_C99_BUILTIN(BUILT_IN_ROUNDL, "roundl", BT_FN_LONGDOUBLE_LONGDOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
 #define ROUND_TYPE(F) BT_FN_##F##_##F
diff --git a/gcc/match.pd b/gcc/match.pd
index 5ba1304af4e..fd77349ed55 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -4686,3 +4686,9 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
 	|| wi::geu_p (wi::to_wide (@rpos),
 		  wi::to_wide (@ipos) + isize))
 (BIT_FIELD_REF @0 @rsize @rpos)
+(simplify
+  (BUILT_IN_ROUNDEVEN real_zerop@0)
+  { build_zero_cst (TREE_TYPE(@0)); })

GSoC 2018 - Adding functions in math.h

[Tejas Joshi]

> * roundeven is similar to existing functions round / ceil / floor / trunc.
> So you'd define built-in functions (roundeven / roundevenf / roundevenl
> and _FloatN and _FloatNx variants) similar to those for the older rounding
> functions, in builtins.def.



Hello,
Thanks to all for your inputs to get me through. As mentioned above, I
have added the function roundeven in match.pd
and its declaration in builtins.def for the testcase 0. Following is
the patch for the same.

For inlining functions, is it the same kind of specialized expansion from
GIMPLE to RTL which is already there for some math functions in bultins.c?
If I get more clear with it, I'd get to go for the proposal.
Thank you.


Regards,
-Tejas

Patch:

diff --git a/gcc/builtins.def b/gcc/builtins.def
index 17f825da367..70640a53347 100644
--- a/gcc/builtins.def
+++ b/gcc/builtins.def
@@ -563,6 +563,7 @@ DEF_C99_BUILTIN(BUILT_IN_RINTL, "rintl",
BT_FN_LONGDOUBLE_LONGDOUBLE, AT
 DEF_EXT_LIB_FLOATN_NX_BUILTINS (BUILT_IN_RINT, "rint", RINT_TYPE,
ATTR_CONST_NOTHROW_LEAF_LIST)
 #undef RINT_TYPE
 DEF_C99_BUILTIN(BUILT_IN_ROUND, "round", BT_FN_DOUBLE_DOUBLE,
ATTR_CONST_NOTHROW_LEAF_LIST)
+DEF_C11_BUILTIN(BUILT_IN_ROUNDEVEN, "roundeven",
BT_FN_DOUBLE_DOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_C99_BUILTIN(BUILT_IN_ROUNDF, "roundf", BT_FN_FLOAT_FLOAT,
ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_C99_BUILTIN(BUILT_IN_ROUNDL, "roundl",
BT_FN_LONGDOUBLE_LONGDOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
 #define ROUND_TYPE(F) BT_FN_##F##_##F
diff --git a/gcc/match.pd b/gcc/match.pd
index 5ba1304af4e..fd77349ed55 100644

--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -4686,3 +4686,9 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
 || wi::geu_p (wi::to_wide (@rpos),
   wi::to_wide (@ipos) + isize))
 (BIT_FIELD_REF @0 @rsize @rpos)
+(simplify
+  (BUILT_IN_ROUNDEVEN real_zerop@0)
+  { build_zero_cst (TREE_TYPE(@0)); })

Cannot compile using cc1.

[Tejas Joshi]

I have gcc source code, stage1-build and test directories as siblings
and I've been trying to compile test.c in test/ using:

../stage1-build/gcc/cc1 test.c

but getting error as:

In file included from test.c:1:
/usr/include/stdio.h:27:10: fatal error: bits/libc-header-start.h: No
such file or directory
27 | #include 
   |  ^~
compilation terminated.

It does compile when stdio.h is not included using #include.
Source code configures and make runs without error.
Any solution or explanation?
Thanks.

About GSOC.

[Tejas Joshi]

Hello.
I reached asking about GCC GSoC project about adding and
folding functions
like roundeven. I could not apply for the idea this year but
interested in the peoject and
really hoping it would be carry forwarded. Since I've been studying
source code and about the project, I think working on this from now
would give me some heads up and hands on with the source code.

I did study .
It does tell that roundeven rounds its argument to nearest integral
ties to even (least significant bit 0) returning integral value
provided that the resulting value is exact.
So, for the start, I'd be implementing this functionality for roundeven.
As ita said in earlier mails that, similar functions like
real_ceil are implemented
in real.c and are used in fold-const-call.c.
Roundeven might be implemented in similar way. Is it built-in
(internal) function means not to be exposed to end-user?
Studying some functions like real_ceil, there are call checks
(flag_errno_math) so I believe similar would be needed for roundeven.

In real.c where real_ceil is implemented, there are function calls
(and implementations) like do_fix_trunc which also then call functions
like decimal_do_dix_trunc (maybe the main functionality of
do_fix_trunc?, other are just checks, like NaN or qNaN). I did not
understand these functions really and what do they do. Also I did not
understand the structure of REAL_VALUE_TYPE (r->cl and etc?)

Also when does the real.c and fold-const-call.c comes in picture in
the flow of GCC (Is it for GIMPLE level instruction selection (gimple
stmnt to corresponding rtl instruction))?
Thanks.

Regards,
-Tejas

Re: About GSOC.

[Tejas Joshi]

About roundeven, there might be need to add case to
expand_builtin_int_roundingfn similar to
ceil, for expansion.
But how is round() expanded since there's no
entry for it in expand_builtin_int_roundingfn ?

Also, is it right to have an added case for roundeven in convert.c
along CASE_FLT_FN (BUILT_IN_ROUND)
in convert_to_integer_1?

Thanks.
On Tue, 23 Oct 2018 at 22:21, Joseph Myers  wrote:
>
> On Tue, 23 Oct 2018, Martin Jambor wrote:
>
> > Hi Joseph,
> >
> > this seems related to your proposal GSoC proposal in the beginning
> > of this year.  Do you have any comments about Tejas's idea?  Do you
>
> My proposal was designed so that it would be possible to do some small
> piece, that is useful by itself, and so learn about some parts of the
> compiler, and then go onto another piece, and so learn about other parts
> of the compiler - as there are lots of separate pieces that are related,
> but each useful by itself as a contribution to GCC.  The parts Tejas
> refers to are good pieces to be looking at for one such piece (roundeven
> folding for constant arguments) (along with e.g. builtins.def to define
> the built-in functions).
>
> > think this would be a good (part of) a GSoC project next year?
>
> If a suitable mentor is available for it next year.
>
> > > It does tell that roundeven rounds its argument to nearest integral
> > > ties to even (least significant bit 0) returning integral value
> > > provided that the resulting value is exact.
> > > So, for the start, I'd be implementing this functionality for roundeven.
> > > As ita said in earlier mails that, similar functions like
> > > real_ceil are implemented
> > > in real.c and are used in fold-const-call.c.
> > > Roundeven might be implemented in similar way. Is it built-in
> > > (internal) function means not to be exposed to end-user?
> > > Studying some functions like real_ceil, there are call checks
> > > (flag_errno_math) so I believe similar would be needed for roundeven.
>
> The expectation for this part of the project would be that calls to both
> __builtin_roundeven and roundeven (and similar functions with f, l, f128
> etc. suffixes) would be folded when the arguments are constants (both
> direct calls with constants such as roundeven (2.5), and cases where
> GIMPLE optimization passes propagate a constant into the call, such as
> "double d = 2.5; return roundeven (d);").  This of course involves various
> internal functions in the compiler to implement that.
>
> If you compile code such as
>
> double
> f (void)
> {
>   double d = 2.5;
>   return ceil (d);
> }
>
> with -O2 -S -fdump-tree-all, you can look at the generated dump files to
> see which optimization pass the folding into constant 3.0 occurs in.
> Looking at such dumps is an important way of finding your way around the
> optimization passes in the compiler.
>
> > > In real.c where real_ceil is implemented, there are function calls
> > > (and implementations) like do_fix_trunc which also then call functions
> > > like decimal_do_dix_trunc (maybe the main functionality of
> > > do_fix_trunc?, other are just checks, like NaN or qNaN). I did not
>
> You can ignore any cases for decimal floating-point values (do gcc_assert
> (!r->decimal)), given that the project does not involve adding any decimal
> floating-point built-in functions.  That means you should instead
> understand REAL_EXP and the significands of floating-point values, and
> what functions such as clear_significand_below and test_significand_bit
> do, because you'll need to write your own logic like that in do_fix_trunc,
> with appropriate cases for whether the bits with values 0.5 and below form
> part of the significand.
>
> > > understand these functions really and what do they do. Also I did not
> > > understand the structure of REAL_VALUE_TYPE (r->cl and etc?)
>
> I suggest looking more closely at the definition of cl in real.h.  It's
> true that it doesn't have a comment specifying its semantics directly, but
> the /* ENUM_BITFIELD (real_value_class) */ should give a strong hint,
> along with the values that are stored in that field.  By looking at how
> all the fields in real_value are used, you should be able to deduce their
> semantics, and then send a GCC patch that adds a comment to each field
> with a more detailed description of its semantics, which would be a useful
> contribution by itself to help people reading real.c code in future.
>
> (struct real_format has more detailed comments on some of the fields.  I
> suggest using those as a model for the comments that ought to be written
> for the fields of struct real_value.)
>
> > > Also when does the real.c and fold-const-call.c comes in picture in
> > > the flow of GCC (Is it for GIMPLE level instruction selection (gimple
> > > stmnt to corresponding rtl instruction))?
>
> The code you're looking at is used in GIMPLE optimizations, and possibly
> folding before GIMPLE.
>
> Converting roundeven calls with non-constant arguments to appropriate
> instructio