Re: [PATCH V2] Optimize '(X - N * M) / N' to 'X / N - M' if valid
Hi, Thanks for your comments! Segher Boessenkool writes: > Hi! > > On Wed, Jun 07, 2023 at 04:21:11PM +0800, Jiufu Guo wrote: >> This patch tries to optimize "(X - N * M) / N" to "X / N - M". >> For C code, "/" towards zero (trunc_div), and "X - N * M" maybe >> wrap/overflow/underflow. So, it is valid that "X - N * M" does >> not cross zero and does not wrap/overflow/underflow. > > Is it ever valid semi-generally when N does not divide X? It is valid only if there is no wrap/overflow/underflow, and the sign of "X" and "X-N*M" are the same. Under this condition, N,M and X can be any value. > > Say X=5, N=2, M=3. Then the original expression evaluates to 0, but the > new one to -1. Whenever one of the divisions rounds up and the other > rounds down you have this problem. You are right. Since '/' is always towards zero, so, 'X' and 'X-N*M' should have the same sign bit. Otherwise, one rounds up, the other rounds down, then the transform is invalid. BR, Jeff (Jiufu Guo) > > > Segher
Re: [PATCH V2] Optimize '(X - N * M) / N' to 'X / N - M' if valid
Hi! On Wed, Jun 07, 2023 at 04:21:11PM +0800, Jiufu Guo wrote: > This patch tries to optimize "(X - N * M) / N" to "X / N - M". > For C code, "/" towards zero (trunc_div), and "X - N * M" maybe > wrap/overflow/underflow. So, it is valid that "X - N * M" does > not cross zero and does not wrap/overflow/underflow. Is it ever valid semi-generally when N does not divide X? Say X=5, N=2, M=3. Then the original expression evaluates to 0, but the new one to -1. Whenever one of the divisions rounds up and the other rounds down you have this problem. Segher
Re: [PATCH V2] Optimize '(X - N * M) / N' to 'X / N - M' if valid
Hi, Richard Biener writes: > On Wed, 7 Jun 2023, Jiufu Guo wrote: > >> Hi, >> >> This patch tries to optimize "(X - N * M) / N" to "X / N - M". >> For C code, "/" towards zero (trunc_div), and "X - N * M" maybe >> wrap/overflow/underflow. So, it is valid that "X - N * M" does >> not cross zero and does not wrap/overflow/underflow. >> >> Compare with previous version: >> https://gcc.gnu.org/pipermail/gcc-patches/2023-May/618796.html >> >> This patch 1. adds the patterns for variable N or M, >> 2. uses simpler form "(X - N * M) / N" for patterns, >> 3. adds functions to gimle-fold.h/cc (not gimple-match-head.cc) >> 4. updates testcases >> >> Bootstrap & regtest pass on ppc64{,le} and x86_64. >> Is this patch ok for trunk? > > Comments below. > >> >> BR, >> Jeff (Jiufu Guo) >> >> PR tree-optimization/108757 >> >> gcc/ChangeLog: >> >> * gimple-fold.cc (maybe_mult_overflow): New function. >> (maybe_plus_overflow): New function. >> (maybe_minus_overflow): New function. >> (plus_mult_no_ovf_and_keep_sign): New function. >> (plus_no_ovf_and_keep_sign): New function. >> * gimple-fold.h (maybe_mult_overflow): New declare. >> (plus_mult_no_ovf_and_keep_sign): New declare. >> (plus_no_ovf_and_keep_sign): New declare. >> * match.pd ((X - N * M) / N): New pattern. >> ((X + N * M) / N): New pattern. >> ((X + C) / N): New pattern. >> ((X + C) >> N): New pattern. >> >> gcc/testsuite/ChangeLog: >> >> * gcc.dg/pr108757-1.c: New test. >> * gcc.dg/pr108757-2.c: New test. >> * gcc.dg/pr108757.h: New test. >> >> --- >> gcc/gimple-fold.cc| 161 >> gcc/gimple-fold.h | 3 + >> gcc/match.pd | 58 +++ >> gcc/testsuite/gcc.dg/pr108757-1.c | 18 +++ >> gcc/testsuite/gcc.dg/pr108757-2.c | 19 +++ >> gcc/testsuite/gcc.dg/pr108757.h | 244 ++ >> 6 files changed, 503 insertions(+) >> create mode 100644 gcc/testsuite/gcc.dg/pr108757-1.c >> create mode 100644 gcc/testsuite/gcc.dg/pr108757-2.c >> create mode 100644 gcc/testsuite/gcc.dg/pr108757.h >> >> diff --git a/gcc/gimple-fold.cc b/gcc/gimple-fold.cc >> index 581575b65ec..bb833ae17b3 100644 >> --- a/gcc/gimple-fold.cc >> +++ b/gcc/gimple-fold.cc >> @@ -9349,3 +9349,164 @@ gimple_stmt_integer_valued_real_p (gimple *stmt, int >> depth) >>return false; >> } >> } >> + >> +/* Return true if "X * Y" may be overflow. */ >> + >> +bool >> +maybe_mult_overflow (value_range , value_range , signop sgn) > > These functions look like some "basic" functionality that should > be (or maybe already is? Andrew?) provided by the value-range > framework. That means it should not reside in gimple-fold.{cc,h} > but elsehwere and possibly with an API close to the existing > value-range stuff. > > Andrew? It would be great to get the overflow info directly from VR :) Now, in range-op.cc, there is aleady value_range_with_overflow and value_range_from_overflowed_bounds which checks OVFs. While this information seems not recorded. Maybe, it is helpful adding a field in VR and adding API to query it. > >> +{ >> + wide_int wmin0 = x.lower_bound (); >> + wide_int wmax0 = x.upper_bound (); >> + wide_int wmin1 = y.lower_bound (); >> + wide_int wmax1 = y.upper_bound (); >> + >> + wi::overflow_type min_ovf, max_ovf; >> + wi::mul (wmin0, wmin1, sgn, _ovf); >> + wi::mul (wmax0, wmax1, sgn, _ovf); >> + if (min_ovf == wi::OVF_NONE && max_ovf == wi::OVF_NONE) >> +{ >> + wi::mul (wmin0, wmax1, sgn, _ovf); >> + wi::mul (wmax0, wmin1, sgn, _ovf); >> + if (min_ovf == wi::OVF_NONE && max_ovf == wi::OVF_NONE) >> +return false; >> +} >> + return true; >> +} >> + >> +/* Return true if "X + Y" may be overflow. */ >> + >> +static bool >> +maybe_plus_overflow (value_range , value_range , signop sgn) >> +{ >> + wide_int wmin0 = x.lower_bound (); >> + wide_int wmax0 = x.upper_bound (); >> + wide_int wmin1 = y.lower_bound (); >> + wide_int wmax1 = y.upper_bound (); >> + >> + wi::overflow_type min_ovf, max_ovf; >> + wi::add (wmax0, wmax1, sgn, _ovf); >> + wi::add (wmin0, wmin1, sgn, _ovf); >> + if (min_ovf == wi::OVF_NONE && max_ovf == wi::OVF_NONE) >> +return false; >> + >> + return true; >> +} >> + >> +/* Return true if "X - Y" may be overflow. */ >> + >> +static bool >> +maybe_minus_overflow (value_range , value_range , signop sgn) >> +{ >> + wide_int wmin0 = x.lower_bound (); >> + wide_int wmax0 = x.upper_bound (); >> + wide_int wmin1 = y.lower_bound (); >> + wide_int wmax1 = y.upper_bound (); >> + >> + wi::overflow_type min_ovf, max_ovf; >> + wi::sub (wmin0, wmax1, sgn, _ovf); >> + wi::sub (wmax0, wmin1, sgn, _ovf); >> + if (min_ovf == wi::OVF_NONE && max_ovf == wi::OVF_NONE) >> +return false; >> + >> + return true; >> +} >> + >> +/* Return true if there is no overflow in the expression. >> + And no sign change on the plus/minus for X. > >
Re: [PATCH V2] Optimize '(X - N * M) / N' to 'X / N - M' if valid
On Wed, 7 Jun 2023, Jiufu Guo wrote: > Hi, > > This patch tries to optimize "(X - N * M) / N" to "X / N - M". > For C code, "/" towards zero (trunc_div), and "X - N * M" maybe > wrap/overflow/underflow. So, it is valid that "X - N * M" does > not cross zero and does not wrap/overflow/underflow. > > Compare with previous version: > https://gcc.gnu.org/pipermail/gcc-patches/2023-May/618796.html > > This patch 1. adds the patterns for variable N or M, > 2. uses simpler form "(X - N * M) / N" for patterns, > 3. adds functions to gimle-fold.h/cc (not gimple-match-head.cc) > 4. updates testcases > > Bootstrap & regtest pass on ppc64{,le} and x86_64. > Is this patch ok for trunk? Comments below. > > BR, > Jeff (Jiufu Guo) > > PR tree-optimization/108757 > > gcc/ChangeLog: > > * gimple-fold.cc (maybe_mult_overflow): New function. > (maybe_plus_overflow): New function. > (maybe_minus_overflow): New function. > (plus_mult_no_ovf_and_keep_sign): New function. > (plus_no_ovf_and_keep_sign): New function. > * gimple-fold.h (maybe_mult_overflow): New declare. > (plus_mult_no_ovf_and_keep_sign): New declare. > (plus_no_ovf_and_keep_sign): New declare. > * match.pd ((X - N * M) / N): New pattern. > ((X + N * M) / N): New pattern. > ((X + C) / N): New pattern. > ((X + C) >> N): New pattern. > > gcc/testsuite/ChangeLog: > > * gcc.dg/pr108757-1.c: New test. > * gcc.dg/pr108757-2.c: New test. > * gcc.dg/pr108757.h: New test. > > --- > gcc/gimple-fold.cc| 161 > gcc/gimple-fold.h | 3 + > gcc/match.pd | 58 +++ > gcc/testsuite/gcc.dg/pr108757-1.c | 18 +++ > gcc/testsuite/gcc.dg/pr108757-2.c | 19 +++ > gcc/testsuite/gcc.dg/pr108757.h | 244 ++ > 6 files changed, 503 insertions(+) > create mode 100644 gcc/testsuite/gcc.dg/pr108757-1.c > create mode 100644 gcc/testsuite/gcc.dg/pr108757-2.c > create mode 100644 gcc/testsuite/gcc.dg/pr108757.h > > diff --git a/gcc/gimple-fold.cc b/gcc/gimple-fold.cc > index 581575b65ec..bb833ae17b3 100644 > --- a/gcc/gimple-fold.cc > +++ b/gcc/gimple-fold.cc > @@ -9349,3 +9349,164 @@ gimple_stmt_integer_valued_real_p (gimple *stmt, int > depth) >return false; > } > } > + > +/* Return true if "X * Y" may be overflow. */ > + > +bool > +maybe_mult_overflow (value_range , value_range , signop sgn) These functions look like some "basic" functionality that should be (or maybe already is? Andrew?) provided by the value-range framework. That means it should not reside in gimple-fold.{cc,h} but elsehwere and possibly with an API close to the existing value-range stuff. Andrew? > +{ > + wide_int wmin0 = x.lower_bound (); > + wide_int wmax0 = x.upper_bound (); > + wide_int wmin1 = y.lower_bound (); > + wide_int wmax1 = y.upper_bound (); > + > + wi::overflow_type min_ovf, max_ovf; > + wi::mul (wmin0, wmin1, sgn, _ovf); > + wi::mul (wmax0, wmax1, sgn, _ovf); > + if (min_ovf == wi::OVF_NONE && max_ovf == wi::OVF_NONE) > +{ > + wi::mul (wmin0, wmax1, sgn, _ovf); > + wi::mul (wmax0, wmin1, sgn, _ovf); > + if (min_ovf == wi::OVF_NONE && max_ovf == wi::OVF_NONE) > + return false; > +} > + return true; > +} > + > +/* Return true if "X + Y" may be overflow. */ > + > +static bool > +maybe_plus_overflow (value_range , value_range , signop sgn) > +{ > + wide_int wmin0 = x.lower_bound (); > + wide_int wmax0 = x.upper_bound (); > + wide_int wmin1 = y.lower_bound (); > + wide_int wmax1 = y.upper_bound (); > + > + wi::overflow_type min_ovf, max_ovf; > + wi::add (wmax0, wmax1, sgn, _ovf); > + wi::add (wmin0, wmin1, sgn, _ovf); > + if (min_ovf == wi::OVF_NONE && max_ovf == wi::OVF_NONE) > +return false; > + > + return true; > +} > + > +/* Return true if "X - Y" may be overflow. */ > + > +static bool > +maybe_minus_overflow (value_range , value_range , signop sgn) > +{ > + wide_int wmin0 = x.lower_bound (); > + wide_int wmax0 = x.upper_bound (); > + wide_int wmin1 = y.lower_bound (); > + wide_int wmax1 = y.upper_bound (); > + > + wi::overflow_type min_ovf, max_ovf; > + wi::sub (wmin0, wmax1, sgn, _ovf); > + wi::sub (wmax0, wmin1, sgn, _ovf); > + if (min_ovf == wi::OVF_NONE && max_ovf == wi::OVF_NONE) > +return false; > + > + return true; > +} > + > +/* Return true if there is no overflow in the expression. > + And no sign change on the plus/minus for X. What does the second sentence mean? sign(X) == sign (X + N*M)? I suppose zero has positive sign? > + CODE is PLUS_EXPR, if the expression is "X + N * M". > + CODE is MINUS_EXPR, if the expression is "X - N * M". > + TYPE is the integer type of the expressions. */ > + > +bool > +plus_mult_no_ovf_and_keep_sign (tree x, tree m, tree n, tree_code code, > + tree type) > +{ > + value_range vr0; > + value_range vr1; > + value_range