* [Bug target/106701] Compiler does not take into account number range limitation to avoid subtract from immediate
[not found] <bug-106701-4@http.gcc.gnu.org/bugzilla/>
@ 2022-08-24 7:57 ` rdapp at gcc dot gnu.org
2022-08-24 10:02 ` rguenth at gcc dot gnu.org
` (3 subsequent siblings)
4 siblings, 0 replies; 5+ messages in thread
From: rdapp at gcc dot gnu.org @ 2022-08-24 7:57 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106701
rdapp at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Target|s390 |s390 x86_64-linux-gnu
CC| |glisse at gcc dot gnu.org,
| |rdapp at gcc dot gnu.org,
| |rguenth at gcc dot gnu.org
Summary|s390: Compiler does not |Compiler does not take into
|take into account number |account number range
|range limitation to avoid |limitation to avoid
|subtract from immediate |subtract from immediate
--- Comment #1 from rdapp at gcc dot gnu.org ---
Added x86 to targets because we don't seem to optimize this there either (at
least I didn't see it on my recent-ish GCC).
The following (not regtested) helps on s390
diff --git a/gcc/match.pd b/gcc/match.pd
index e486b4be282c..2ebbf68010f9 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -7992,3 +7992,27 @@ and,
(match (bitwise_induction_p @0 @2 @3)
(bit_not
(nop_convert1? (bit_xor@0 (convert2? (lshift integer_onep@1 @2)) @3))))
+
+/* cst - a -> cst ^ a if 0 >= a <= cst and integer_pow2p (cst + 1). */
+#if GIMPLE
+(simplify
+ (minus INTEGER_CST@0 @1)
+ (with {
+ wide_int w = wi::to_wide (@0) + 1;
+ value_range vr;
+ wide_int wmin = w;
+ wide_int wmax = w;
+ if (get_global_range_query ()->range_of_expr (vr, @1)
+ && vr.kind () == VR_RANGE)
+ {
+ wmin = vr.lower_bound ();
+ wmax = vr.upper_bound ();
+ }
+ }
+ (if (wi::exact_log2 (w) != -1
+ && wi::geu_p (wmin, 0)
+ && wi::leu_p (wmax, w))
+ (bit_xor @0 @1))
+ )
+)
+#endif
but it can surely be improved by some match.pd magic still. A second question
would be, do we unconditionally want to simplify this or should it rather be
backend dependent?
^ permalink raw reply [flat|nested] 5+ messages in thread* [Bug target/106701] Compiler does not take into account number range limitation to avoid subtract from immediate
[not found] <bug-106701-4@http.gcc.gnu.org/bugzilla/>
2022-08-24 7:57 ` [Bug target/106701] Compiler does not take into account number range limitation to avoid subtract from immediate rdapp at gcc dot gnu.org
@ 2022-08-24 10:02 ` rguenth at gcc dot gnu.org
2022-08-24 12:02 ` rdapp at gcc dot gnu.org
` (2 subsequent siblings)
4 siblings, 0 replies; 5+ messages in thread
From: rguenth at gcc dot gnu.org @ 2022-08-24 10:02 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106701
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
I'd say all single-operation magic shouldn't happen in match.pd, this really
looks like something for RTL expansion to decide. For example some targets
might have instructions that can either do cst - a or cst ^ a with an immediate
(when integer_pow2p (cst + 1)).
match.pd should be about canonicalization here (none of the two is "simpler"),
but canonicalization based on value-range looks a bit iffy.
^ permalink raw reply [flat|nested] 5+ messages in thread* [Bug target/106701] Compiler does not take into account number range limitation to avoid subtract from immediate
[not found] <bug-106701-4@http.gcc.gnu.org/bugzilla/>
2022-08-24 7:57 ` [Bug target/106701] Compiler does not take into account number range limitation to avoid subtract from immediate rdapp at gcc dot gnu.org
2022-08-24 10:02 ` rguenth at gcc dot gnu.org
@ 2022-08-24 12:02 ` rdapp at gcc dot gnu.org
2022-08-24 13:45 ` rguenther at suse dot de
2022-08-24 15:02 ` pinskia at gcc dot gnu.org
4 siblings, 0 replies; 5+ messages in thread
From: rdapp at gcc dot gnu.org @ 2022-08-24 12:02 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106701
--- Comment #3 from rdapp at gcc dot gnu.org ---
I though expand (or combine) were independent of value range. What would be the
proper place for it then?
^ permalink raw reply [flat|nested] 5+ messages in thread* [Bug target/106701] Compiler does not take into account number range limitation to avoid subtract from immediate
[not found] <bug-106701-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2022-08-24 12:02 ` rdapp at gcc dot gnu.org
@ 2022-08-24 13:45 ` rguenther at suse dot de
2022-08-24 15:02 ` pinskia at gcc dot gnu.org
4 siblings, 0 replies; 5+ messages in thread
From: rguenther at suse dot de @ 2022-08-24 13:45 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106701
--- Comment #4 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 24 Aug 2022, rdapp at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106701
>
> --- Comment #3 from rdapp at gcc dot gnu.org ---
> I though expand (or combine) were independent of value range. What would be the
> proper place for it then?
I think we use ranges during expansion already, otherwise gimple-isel.cc
might be a good place.
^ permalink raw reply [flat|nested] 5+ messages in thread* [Bug target/106701] Compiler does not take into account number range limitation to avoid subtract from immediate
[not found] <bug-106701-4@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2022-08-24 13:45 ` rguenther at suse dot de
@ 2022-08-24 15:02 ` pinskia at gcc dot gnu.org
4 siblings, 0 replies; 5+ messages in thread
From: pinskia at gcc dot gnu.org @ 2022-08-24 15:02 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106701
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |DUPLICATE
Status|UNCONFIRMED |RESOLVED
--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Dup of bug 91213.
*** This bug has been marked as a duplicate of bug 91213 ***
^ permalink raw reply [flat|nested] 5+ messages in thread