[Bug middle-end/111324] More optimization about "(X * Y) / Y"

[guojiufu at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111324

--- Comment #7 from Jiu Fu Guo  ---
A comment https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111303#c7 
should be attached here.

[Bug middle-end/111324] More optimization about "(X * Y) / Y"

[guojiufu at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111324

Jiu Fu Guo  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Jiu Fu Guo  ---
This can be handled by r14-3913-g8d8bc560b6ab7f3153db23ffb37157528e5b2c9a.

[Bug middle-end/111324] More optimization about "(X * Y) / Y"

[guojiufu at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111324

--- Comment #5 from Jiu Fu Guo  ---
(In reply to Andrew Pinski from comment #2)
> Confirmed. 
> 
> So using the local range in this case is ok. There might be only a few times
> we don't want to use it though in match.

Agree, "get_range_query" would be more useful for most cases.


Through a quick look at match.pd, there are another two patterns that use
"get_global_range_query".

Some concerns about those patterns, so those patterns may not need to be
updated.

* (T)(A)+cst -->(T)(A+cst): I'm wondering if this transformation is really in
favor of PPC.
e.g. "return (long) x1 + 40;" could save one "extend-insn" less than "return
(long)(x1 + 40);"

* For pattern "((x * cst) + cst1) * cst2": it seems this pattern does not
affect any cases. I mean this optimization is done by other parts (before
match.pd).

[Bug middle-end/111324] More optimization about "(X * Y) / Y"

[guojiufu at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111324

--- Comment #4 from Jiu Fu Guo  ---
(In reply to Jiu Fu Guo from comment #3)
> A patch is posted:
> https://gcc.gnu.org/pipermail/gcc-patches/2023-September/629534.html
It is not for this PR. Sorry for typo.

[Bug middle-end/111324] More optimization about "(X * Y) / Y"

[guojiufu at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111324

--- Comment #3 from Jiu Fu Guo  ---
A patch is posted:
https://gcc.gnu.org/pipermail/gcc-patches/2023-September/629534.html

[Bug middle-end/111324] More optimization about "(X * Y) / Y"

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111324

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Keywords||missed-optimization
   Last reconfirmed||2023-09-07
   Severity|normal  |enhancement
 CC||pinskia at gcc dot gnu.org

--- Comment #2 from Andrew Pinski  ---
Confirmed. 

So using the local range in this case is ok. There might be only a few times we
don't want to use it though in match.

Here is a testcase where we should just change it into "return x;" but don't
yet:
```
typedef unsigned int INT;

INT
foo (INT x, INT y)
{
  if (x > 100 || y > 100)
return x;
  return (x * y) / y;
}
```

Note clang is able to change it though.

[Bug middle-end/111324] More optimization about "(X * Y) / Y"

[guojiufu at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111324

--- Comment #1 from Jiu Fu Guo  ---
In match.pd, there is a pattern:

/* Simplify (t * 2) / 2) -> t.  */
(for div (trunc_div ceil_div floor_div round_div exact_div)
 (simplify
  (div (mult:c @0 @1) @1)
  (if (ANY_INTEGRAL_TYPE_P (type))
   (if (TYPE_OVERFLOW_UNDEFINED (type))
@0
#if GIMPLE
(with
 {
   bool overflowed = true;
   value_range vr0, vr1;
   if (INTEGRAL_TYPE_P (type)
   && get_global_range_query ()->range_of_expr (vr0, @0)
   && get_global_range_query ()->range_of_expr (vr1, @1)
   && !vr0.varying_p () && !vr0.undefined_p ()
   && !vr1.varying_p () && !vr1.undefined_p ())
 {

Here, "get_global_range_query" is able to get the value-range info for SSA.
But it does not handle the case t.c. "get_range_query" can handle it.