[PATCH] PR tree-optimization/105835: Two narrowing patterns for match.pd.

[PATCH] PR tree-optimization/105835: Two narrowing patterns for match.pd.

[Roger Sayle]

[-- Attachment #1: Type: text/plain, Size: 1794 bytes --]


This patch resolves PR tree-optimization/105835, which is a code quality
(dead code elimination) regression at -O1 triggered/exposed by a recent
change to canonicalize X&-Y as X*Y.  The new (shorter) form exposes some
missed optimization opportunities that can be handled by adding some
extra simplifications to match.pd.

One transformation is to simplify "(short)(x ? 65535 : 0)" into the
equivalent "x ? -1 : 0", or more accurately x ? (short)-1 : (short)0",
as INTEGER_CSTs record their type, and integer conversions can be
pushed inside COND_EXPRs reducing the number of gimple statements.

The other transformation is that (short)(X * 65535), where X is [0,1],
into the equivalent (short)X * -1, (or again (short)-1 where tree's
INTEGER_CSTs encode their type).  This is valid because multiplications
where one operand is [0,1] are guaranteed not to overflow, and hence
integer conversions can also be pushed inside these multiplications.

These narrowing conversion optimizations can be identified by range
analyses, such as EVRP, but these are only performed at -O2 and above,
which is why this regression is only visible with -O1.

This patch has been tested on x86_64-pc-linux-gnu with make bootstrap
and make -k check, both with and without --target_board=unix{-m32}
with no new failures.  Ok for mainline?


2022-06-05  Roger Sayle  <roger@nextmovesoftware.com>

gcc/ChangeLog
        * match.pd (convert (mult zero_one_valued_p@1 INTEGER_CST@2)):
        Narrow integer multiplication by a zero_one_valued_p operand.
        (convert (cond @1 INTEGER_CST@2 INTEGER_CST@3)): Push integer
        conversions inside COND_EXPR where both data operands are
        integer constants.

gcc/testsuite/ChangeLog
        * gcc.dg/pr105835.c: New test case.


Thanks in advance,
Roger
--


[-- Attachment #2: patchfc.txt --]
[-- Type: text/plain, Size: 1685 bytes --]

diff --git a/gcc/match.pd b/gcc/match.pd
index 2d3ffc4..d705947 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -1800,6 +1800,15 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
       && !TYPE_UNSIGNED (TREE_TYPE (@0)))
   (mult (convert @0) @1)))
 
+/* Narrow integer multiplication by a zero_one_valued_p operand.
+   Multiplication by [0,1] is guaranteed not to overflow.  */
+(simplify
+ (convert (mult@0 zero_one_valued_p@1 INTEGER_CST@2))
+ (if (INTEGRAL_TYPE_P (type)
+      && INTEGRAL_TYPE_P (TREE_TYPE (@0))
+      && TYPE_PRECISION (type) <= TYPE_PRECISION (TREE_TYPE (@0)))
+  (mult (convert @1) (convert @2))))
+
 /* Convert ~ (-A) to A - 1.  */
 (simplify
  (bit_not (convert? (negate @0)))
@@ -4265,6 +4274,12 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
 )
 #endif
 
+(simplify
+ (convert (cond@0 @1 INTEGER_CST@2 INTEGER_CST@3))
+ (if (INTEGRAL_TYPE_P (type)
+      && INTEGRAL_TYPE_P (TREE_TYPE (@0)))
+  (cond @1 (convert @2) (convert @3))))
+
 /* Simplification moved from fold_cond_expr_with_comparison.  It may also
    be extended.  */
 /* This pattern implements two kinds simplification:
diff --git a/gcc/testsuite/gcc.dg/pr105835.c b/gcc/testsuite/gcc.dg/pr105835.c
new file mode 100644
index 0000000..354c81c
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr105835.c
@@ -0,0 +1,18 @@
+/* { dg-do compile } */
+/* { dg-options "-O1 -fdump-tree-optimized" } */
+
+void foo();
+
+static int b;
+
+static short a(short c, unsigned short d) { return c - d; }
+
+int main() {
+    int e = -(0 < b);
+    if (a(1, e))
+        b = 0;
+    else
+        foo();
+}
+
+/* { dg-final { scan-tree-dump-not "goto" "optimized" } } */

Re: [PATCH] PR tree-optimization/105835: Two narrowing patterns for match.pd.

[Jeff Law]

On 6/5/2022 7:12 AM, Roger Sayle wrote:
> This patch resolves PR tree-optimization/105835, which is a code quality
> (dead code elimination) regression at -O1 triggered/exposed by a recent
> change to canonicalize X&-Y as X*Y.  The new (shorter) form exposes some
> missed optimization opportunities that can be handled by adding some
> extra simplifications to match.pd.
>
> One transformation is to simplify "(short)(x ? 65535 : 0)" into the
> equivalent "x ? -1 : 0", or more accurately x ? (short)-1 : (short)0",
> as INTEGER_CSTs record their type, and integer conversions can be
> pushed inside COND_EXPRs reducing the number of gimple statements.
>
> The other transformation is that (short)(X * 65535), where X is [0,1],
> into the equivalent (short)X * -1, (or again (short)-1 where tree's
> INTEGER_CSTs encode their type).  This is valid because multiplications
> where one operand is [0,1] are guaranteed not to overflow, and hence
> integer conversions can also be pushed inside these multiplications.
>
> These narrowing conversion optimizations can be identified by range
> analyses, such as EVRP, but these are only performed at -O2 and above,
> which is why this regression is only visible with -O1.
>
> This patch has been tested on x86_64-pc-linux-gnu with make bootstrap
> and make -k check, both with and without --target_board=unix{-m32}
> with no new failures.  Ok for mainline?
>
>
> 2022-06-05  Roger Sayle  <roger@nextmovesoftware.com>
>
> gcc/ChangeLog
>          * match.pd (convert (mult zero_one_valued_p@1 INTEGER_CST@2)):
>          Narrow integer multiplication by a zero_one_valued_p operand.
>          (convert (cond @1 INTEGER_CST@2 INTEGER_CST@3)): Push integer
>          conversions inside COND_EXPR where both data operands are
>          integer constants.
>
> gcc/testsuite/ChangeLog
>          * gcc.dg/pr105835.c: New test case.
OK
jeff