[Bug target/106701] Compiler does not take into account number range limitation to avoid subtract from immediate

[rdapp at gcc dot gnu.org]

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?