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
