GCC GSoC project idea to make C/C++ not promote memory_order_consume to memory_order_acquire
Hi, I have received the following idea for a Google Summer of Code project, see the quotation from Paul McKenney below (I do not know myself where exactly it is from). I consider memory consistency models a very tough topic and so am doubly reluctant to just post it to wiki without having a mentor for it. On the other hand, with the right mentors it definitely can be quite a remarkable project with a big potential. Paul, this may come as a surprise for you, but would you be willing to (co-)mentor such a project if there is a student brave enough to undertake it? C++ front-end guys, would you please consider co-mentoring this project if Paul was willing to do so? Anybody else interested in getting involved? Any other suggestions/comments? Thank you very much in advance, Martin Start of forwarded message Hi Martin, I don't think I have a mentor for this yet though I wonder if Paul McKenney could be persuaded for this from the memory model side and someone familiar with the C++ frontend on the GCC side ? -- One could argue that compilers in fact implement the C and C++ memory_order_consume facility. However, all known compilers do so by promoting it to memory_order_acquire, which on weakly ordered systems can result in unnecessary memory-barrier instructions on your fastpaths, which might not be what you want. The reason for the promotion to memory_order_acquire is the difficutlies faced by compiler writers when attempting to trace dependencies at the C/C++ source-code level. In fact, there is a proposal to temporarily deprecate memory_order_consume [1]. So what is to be done? One proposal [2] restricts dependency chains to cases where it is difficult for the compiler to break them, and further requires that pointer variables carrying dependencies be marked. (This proposal also includes prototype wording for the C++ standard, a number of litmus tests, and some discussion.) Such marking might not go down well with the Linux kernel community, which has been carrying dependencies in unmarked variables for more than 15 years, so there is further informal proposal asking C and C++ implementations to provide a command-line option forcing the compiler to treat any pointer variable as if it had been marked. (Why informal? Because command-line options are outside of the scope of the standard.) There is a prototype implementation that obtains the functionality of memory_order_consume without actually using memory_order_consume, which is briefly described in a recent C++ working paper [3]. However, the committee was not all that happy with this approach, preferring marking of a single pointer variable to maintaining a separate variable to carry the dependency. It would therefore be quite desirable to have an implementation that allowed pointers to be marked as carrying dependencies, that avoided the specified dependency-breaking optimizations on such pointers, and that provided a command-line switch that caused the compiler to treat all pointers as if they were to marked [2]. [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0371r0.html [2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0190r4.pdf [3] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0750r1.html --- Ramana End of forwarded message
Fwd: How to gimplify_build a FMA_EXPR since it was removed?
Sorry for duplicate, gcc-help was not the right mailing list for this one. Original Message Subject: How to gimplify_build a FMA_EXPR since it was removed? Date: Monday, February 04, 2019 13:28 CET From: Laurent Thévenoux To: gcc-h...@gcc.gnu.org CC: richard.sandif...@linaro.org Hi, I've developed some code in gcc/tree-complex.c. I was using the FMA_EXPR to generate fma operations such as in: ``` rr = gimplify_build3 (gsi, FMA_EXPR, inner_type, ai, ai, p1r);``` FMA_EXPR was removed in https://gcc.gnu.org/ml/gcc-patches/2018-05/msg00570.html. Is there an easy way to gimplify FMAs with the new functions introduced in the patch below? Thanks, Laurent
Re: About GSOC.
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.
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. 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.
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. 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
diff --git a/gcc/builtins.c b/gcc/builtins.c
index 25e01e4092b..25282d2122d 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_FLOATN (ROUNDEVEN)
CASE_MATHFN (SCALB)
CASE_MATHFN (SCALBLN)
CASE_MATHFN (SCALBN)
diff --git a/gcc/builtins.def b/gcc/builtins.def
index ef89729fd0c..f1b6830a49c 100644
--- a/gcc/builtins.def
+++ b/gcc/builtins.def
@@ -308,6 +308,7 @@ DEF_C99_BUILTIN(BUILT_IN_CBRT, "cbrt", BT_FN_DOUBLE_DOUBLE, ATTR_MATHFN_
DEF_C99_BUILTIN(BUILT_IN_CBRTF, "cbrtf", BT_FN_FLOAT_FLOAT, ATTR_MATHFN_FPROUNDING)
DEF_C99_BUILTIN(BUILT_
Re: About GSOC.
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 (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: GCC GSoC project idea to make C/C++ not promote memory_order_consume to memory_order_acquire
On Mon, Feb 4, 2019 at 6:06 AM Martin Jambor wrote: > > I have received the following idea for a Google Summer of Code project, > see the quotation from Paul McKenney below (I do not know myself where > exactly it is from). I consider memory consistency models a very tough > topic and so am doubly reluctant to just post it to wiki without having > a mentor for it. On the other hand, with the right mentors it > definitely can be quite a remarkable project with a big potential. > > Paul, this may come as a surprise for you, but would you be willing to > (co-)mentor such a project if there is a student brave enough to > undertake it? > > C++ front-end guys, would you please consider co-mentoring this project > if Paul was willing to do so? I wouldn't expect this project to touch the C++ front-end at all; any compiler work would all be in the middle/back-end. There's some previous discussion of these issues at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448 So I'd suggest pinging Andrew Macleod. Jason > Anybody else interested in getting involved? > > Any other suggestions/comments? > > Thank you very much in advance, > > Martin > > > Start of forwarded message > > Hi Martin, > > I don't think I have a mentor for this yet though I wonder if Paul McKenney > could be persuaded for this from the memory model side and someone familiar > with the C++ frontend on the GCC side ? > > > -- > > One could argue that compilers in fact implement the C and C++ > memory_order_consume facility. However, all known compilers do so by > promoting it to memory_order_acquire, which on weakly ordered systems > can result in unnecessary memory-barrier instructions on your fastpaths, > which might not be what you want. The reason for the promotion to > memory_order_acquire is the difficutlies faced by compiler writers when > attempting to trace dependencies at the C/C++ source-code level. In fact, > there is a proposal to temporarily deprecate memory_order_consume [1]. > > So what is to be done? One proposal [2] restricts dependency chains > to cases where it is difficult for the compiler to break them, and > further requires that pointer variables carrying dependencies be marked. > (This proposal also includes prototype wording for the C++ standard, > a number of litmus tests, and some discussion.) Such marking might not > go down well with the Linux kernel community, which has been carrying > dependencies in unmarked variables for more than 15 years, so there is > further informal proposal asking C and C++ implementations to provide a > command-line option forcing the compiler to treat any pointer variable > as if it had been marked. (Why informal? Because command-line options > are outside of the scope of the standard.) > > There is a prototype implementation that obtains the functionality of > memory_order_consume without actually using memory_order_consume, which > is briefly described in a recent C++ working paper [3]. However, the > committee was not all that happy with this approach, preferring marking > of a single pointer variable to maintaining a separate variable to carry > the dependency. > > It would therefore be quite desirable to have an implementation that > allowed pointers to be marked as carrying dependencies, that avoided > the specified dependency-breaking optimizations on such pointers, and > that provided a command-line switch that caused the compiler to treat > all pointers as if they were to marked [2]. > > > [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0371r0.html > [2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0190r4.pdf > [3] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0750r1.html > > --- > > Ramana > End of forwarded message
Re: About GSOC.
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 (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 op
Re: How to gimplify_build a FMA_EXPR since it was removed?
On Mon, Feb 4, 2019 at 4:47 AM Laurent Thévenoux wrote: > > Sorry for duplicate, gcc-help was not the right mailing list for this one. > > > Original Message > Subject: How to gimplify_build a FMA_EXPR since it was removed? > Date: Monday, February 04, 2019 13:28 CET > From: Laurent Thévenoux > To: gcc-h...@gcc.gnu.org > CC: richard.sandif...@linaro.org > > > > Hi, > > I've developed some code in gcc/tree-complex.c. I was using the > FMA_EXPR to generate fma operations such as in: > > ``` > rr = gimplify_build3 (gsi, FMA_EXPR, inner_type, ai, ai, p1r);``` > > FMA_EXPR was removed in > https://gcc.gnu.org/ml/gcc-patches/2018-05/msg00570.html. > > Is there an easy way to gimplify FMAs with the new functions > introduced in the patch below? From that patch (e.g. rs6000_gimple_fold_builtin): - gimple *g = gimple_build_assign (lhs, FMA_EXPR, arg0, arg1, arg2); + gcall *g = gimple_build_call_internal (IFN_FMA, 3, arg0, arg1, arg2); + gimple_call_set_lhs (g, lhs); + gimple_call_set_nothrow (g, true); Thanks, Andrew Pinski > > Thanks, > Laurent >
Re: How to gimplify_build a FMA_EXPR since it was removed?
Hi,
Thanks for pointing this me out. Nevertheless, I’m not sure this can apply in
my case since gimple_build_call_internal() returns a gimple data type while
gimplify_build3() returns a tree data type. I’ll try to figure how faisable is
to use it in my case. For more context, see the code snippet below.
```
static void
some_fn (gimple_stmt_iterator *gsi, tree inner_type, tree ar, tree ai, tree br,
tree bi)
{
tree rr, ri, pr1;
p1r = gimplify_build2 (gsi, MULT_EXPR, inner_type, ar, ar);
rr = gimplify_build3 (gsi, FMA_EXPR, inner_type, ai, ai, p1r);
ri = build_real (inner_type, dconst0);
update_complex_assignment (gsi, rr, ri);
}
```
> Le 4 févr. 2019 à 23:38, Andrew Pinski a écrit :
>
> On Mon, Feb 4, 2019 at 4:47 AM Laurent Thévenoux wrote:
>>
>> Sorry for duplicate, gcc-help was not the right mailing list for this one.
>>
>>
>> Original Message
>> Subject: How to gimplify_build a FMA_EXPR since it was removed?
>> Date: Monday, February 04, 2019 13:28 CET
>> From: Laurent Thévenoux
>> To: gcc-h...@gcc.gnu.org
>> CC: richard.sandif...@linaro.org
>>
>>
>>
>> Hi,
>>
>> I've developed some code in gcc/tree-complex.c. I was using the
>> FMA_EXPR to generate fma operations such as in:
>>
>> ```
>> rr = gimplify_build3 (gsi, FMA_EXPR, inner_type, ai, ai, p1r);```
>>
>> FMA_EXPR was removed in
>> https://gcc.gnu.org/ml/gcc-patches/2018-05/msg00570.html.
>>
>> Is there an easy way to gimplify FMAs with the new functions
>> introduced in the patch below?
>
> From that patch (e.g. rs6000_gimple_fold_builtin):
>
> - gimple *g = gimple_build_assign (lhs, FMA_EXPR, arg0, arg1, arg2);
> + gcall *g = gimple_build_call_internal (IFN_FMA, 3, arg0, arg1, arg2);
> + gimple_call_set_lhs (g, lhs);
> + gimple_call_set_nothrow (g, true);
>
>
> Thanks,
> Andrew Pinski
>
>
>>
>> Thanks,
>> Laurent
Re: How to gimplify_build a FMA_EXPR since it was removed?
On Mon, Feb 4, 2019 at 3:13 PM Laurent Thévenoux wrote:
>
> Hi,
>
> Thanks for pointing this me out. Nevertheless, I’m not sure this can apply in
> my case since gimple_build_call_internal() returns a gimple data type while
> gimplify_build3() returns a tree data type. I’ll try to figure how faisable
> is to use it in my case. For more context, see the code snippet below.
You need to create a new temp ssa name to hold the FMA results. There
are few examples in the tree-ssa-phi-opt.c code for on how to use this
way instead of using gimplify_build3.
Thanks,
Andrew Pinski
>
> ```
> static void
> some_fn (gimple_stmt_iterator *gsi, tree inner_type, tree ar, tree ai, tree
> br, tree bi)
> {
> tree rr, ri, pr1;
>
> p1r = gimplify_build2 (gsi, MULT_EXPR, inner_type, ar, ar);
> rr = gimplify_build3 (gsi, FMA_EXPR, inner_type, ai, ai, p1r);
> ri = build_real (inner_type, dconst0);
> update_complex_assignment (gsi, rr, ri);
> }
>
> ```
>
> > Le 4 févr. 2019 à 23:38, Andrew Pinski a écrit :
> >
> > On Mon, Feb 4, 2019 at 4:47 AM Laurent Thévenoux wrote:
> >>
> >> Sorry for duplicate, gcc-help was not the right mailing list for this one.
> >>
> >>
> >> Original Message
> >> Subject: How to gimplify_build a FMA_EXPR since it was removed?
> >> Date: Monday, February 04, 2019 13:28 CET
> >> From: Laurent Thévenoux
> >> To: gcc-h...@gcc.gnu.org
> >> CC: richard.sandif...@linaro.org
> >>
> >>
> >>
> >> Hi,
> >>
> >> I've developed some code in gcc/tree-complex.c. I was using the
> >> FMA_EXPR to generate fma operations such as in:
> >>
> >> ```
> >> rr = gimplify_build3 (gsi, FMA_EXPR, inner_type, ai, ai, p1r);```
> >>
> >> FMA_EXPR was removed in
> >> https://gcc.gnu.org/ml/gcc-patches/2018-05/msg00570.html.
> >>
> >> Is there an easy way to gimplify FMAs with the new functions
> >> introduced in the patch below?
> >
> > From that patch (e.g. rs6000_gimple_fold_builtin):
> >
> > - gimple *g = gimple_build_assign (lhs, FMA_EXPR, arg0, arg1, arg2);
> > + gcall *g = gimple_build_call_internal (IFN_FMA, 3, arg0, arg1, arg2);
> > + gimple_call_set_lhs (g, lhs);
> > + gimple_call_set_nothrow (g, true);
> >
> >
> > Thanks,
> > Andrew Pinski
> >
> >
> >>
> >> Thanks,
> >> Laurent
>
