On Tue, Oct 25, 2016 at 1:00 PM, Richard Biener
<richard.guent...@gmail.com> wrote:
> On Tue, Oct 25, 2016 at 1:21 PM, Bin Cheng <bin.ch...@arm.com> wrote:
>> Hi,
>> This is an update patch for
>> https://gcc.gnu.org/ml/gcc-patches/2016-10/msg00738.html . In this version,
>> existing pattern (convert (op:s (convert@2 @0) (convert?@3 @1))) is
>> extended. It allows narrowing of arithmetic operation which has constant
>> integer as its second operand. It also simplifies next patch handling
>> cond_expr.
>> Bootstrap and test on x86_64 and AArch64 for whole patch set. Is it OK?
>
> + && types_match (@0, type)
> + && (types_match (@0, @1)
> + /* Or the second operand must be constant integer. */
> + || (@3 == @1
> + && types_match (@1, @2)
> + && TREE_CODE (@1) == INTEGER_CST)))
>
> So this fails to match the pattern if we get into it via valueization
> and get, say,
> (short)((int)a + (int)7). I believe for plus and minus we're always safe so
> I suggest to simply do
>
> && (types_match (@0, @1)
> || TREE_CODE (@1) == INTEGER_CST)
>
> (if (TYPE_OVERFLOW_WRAPS (TREE_TYPE (@0)))
> - (convert (op @0 @1))
> + (convert (op @0 (convert:type @1)))
>
> :type shouldn't be necessary -- it also shows the outer (convert ..)
> is not required,
> please remove it while you're here.
>
> (with { tree utype = unsigned_type_for (TREE_TYPE (@0)); }
> - (convert (op (convert:utype @0) (convert:utype @1))))))))
> + (convert (op (convert:utype @0)
> + (convert:utype (convert:type @1)))))))))
>
> Why do you need the intermediate conversion?
Thanks for reviewing, updated patch attached. Is it OK?
Thanks,
bin
diff --git a/gcc/match.pd b/gcc/match.pd
index 01d088d..dbe11bc 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -3328,7 +3328,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
operation and convert the result to the desired type. */
(for op (plus minus)
(simplify
- (convert (op:s (convert@2 @0) (convert@3 @1)))
+ (convert (op:s (convert@2 @0) (convert?@3 @1)))
(if (INTEGRAL_TYPE_P (type)
/* We check for type compatibility between @0 and @1 below,
so there's no need to check that @1/@3 are integral types. */
@@ -3344,12 +3344,16 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
&& TYPE_PRECISION (type) == GET_MODE_PRECISION (TYPE_MODE (type))
/* The inner conversion must be a widening conversion. */
&& TYPE_PRECISION (TREE_TYPE (@2)) > TYPE_PRECISION (TREE_TYPE (@0))
- && types_match (@0, @1)
- && types_match (@0, type))
+ && types_match (@0, type)
+ && (types_match (@0, @1)
+ /* Or the second operand is const integer or converted const
+ integer from valueize. */
+ || TREE_CODE (@1) == INTEGER_CST))
(if (TYPE_OVERFLOW_WRAPS (TREE_TYPE (@0)))
- (convert (op @0 @1))
+ (op @0 (convert @1))
(with { tree utype = unsigned_type_for (TREE_TYPE (@0)); }
- (convert (op (convert:utype @0) (convert:utype @1))))))))
+ (convert (op (convert:utype @0)
+ (convert:utype @1))))))))
/* This is another case of narrowing, specifically when there's an outer
BIT_AND_EXPR which masks off bits outside the type of the innermost
diff --git a/gcc/testsuite/gcc.dg/fold-narrowbopcst-1.c
b/gcc/testsuite/gcc.dg/fold-narrowbopcst-1.c
new file mode 100644
index 0000000..8a33677
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/fold-narrowbopcst-1.c
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+/* { dg-options "-O1 -fdump-tree-optimized" } */
+
+int foo1 (unsigned char a[], unsigned int x)
+{
+ unsigned int i;
+ for (i = 0; i < 1000; i++)
+ {
+ x = a[i];
+ a[i] = (unsigned char)(x >= 100 ? x - 100 : 0);
+ }
+ return x;
+}
+/* { dg-final { scan-tree-dump " = _.* \\+ 156" "optimized" } } */
