Move some comparison simplifications to match.pd

Kyrill Tkachov kyrylo.tkachov@arm.com
Tue Oct 27 15:33:00 GMT 2015


Hi Marc,

On 30/08/15 08:57, Marc Glisse wrote:
> Hello,
>
> just trying to shrink fold-const.c a bit more.
>
> initializer_zerop is close to what I was looking for with zerop, but I
> wasn't sure if it would be safe (it accepts some CONSTRUCTOR and
> STRING_CST). At some point I tried using sign_bit_p, but using the return
> of that function in the simplification confused the machinery too much. I
> added an "overload" of element_precision like the one in element_mode, for
> convenience.
>
> Bootstrap+testsuite on ppc64le-redhat-linux.
>
>
> 2015-08-31  Marc Glisse  <marc.glisse@inria.fr>
>
> gcc/
>   	* tree.h (zerop): New function.
>   	* tree.c (zerop): Likewise.
>   	(element_precision): Handle expressions.
>   	* match.pd (define_predicates): Add zerop.
>   	(x <= +Inf): Fix comment.
>   	(abs (x) == 0, A & C == C, A & C != 0): Converted from ...
>   	* fold-const.c (fold_binary_loc): ... here. Remove.
>
> gcc/testsuite/
>   	* gcc.dg/tree-ssa/cmp-1.c: New file.
>

+/* If we have (A & C) != 0 where C is the sign bit of A, convert
+   this into A < 0.  Similarly for (A & C) == 0 into A >= 0.  */
+(for cmp (eq ne)
+     ncmp (ge lt)
+ (simplify
+  (cmp (bit_and (convert?@2 @0) integer_pow2p@1) integer_zerop)
+  (if (INTEGRAL_TYPE_P (TREE_TYPE (@0))
+       && (TYPE_PRECISION (TREE_TYPE (@0))
+	   == GET_MODE_PRECISION (TYPE_MODE (TREE_TYPE (@0))))
+       && element_precision (@2) >= element_precision (@0)
+       && wi::only_sign_bit_p (@1, element_precision (@0)))
+   (with { tree stype = signed_type_for (TREE_TYPE (@0)); }
+    (ncmp (convert:stype @0) { build_zero_cst (stype); })))))
+

With this patch and this pattern pattern in particular I've seen some code quality regressions on aarch64.
I'm still trying to reduce a testcase to demonstrate the issue but it seems to involve
intorucing extra conversions from unsigned to signed values. If I gate this pattern on
!TYPE_UNSIGNED (TREE_TYPE (@0)) the codegen seems to improve.

Any thoughts?
Thanks,
Kyrill




More information about the Gcc-patches mailing list