On Fri, 6 Dec 2019, Jakub Jelinek wrote:
--- gcc/match.pd.jj 2019-12-06 14:07:26.877749065 +0100
+++ gcc/match.pd 2019-12-06 15:06:08.042953309 +0100
@@ -2697,6 +2697,31 @@ (define_operator_list COND_TERNARY
(cmp (minmax @0 INTEGER_CST@1) INTEGER_CST@2)
(comb (cmp @0 @2) (cmp @1 @2))))
+/* Undo fancy way of writing max/min or other ?: expressions,
+ like a - ((a - b) & -(a < b)), in this case into (a < b) ? b : a.
+ People normally use ?: and that is what we actually try to optimize. */
+(for cmp (simple_comparison)
+ (simplify
+ (minus @0 (bit_and:c (minus @0 @1)
+ (convert? (negate@4 (convert? (cmp@5 @2 @3))))))
+ (if (INTEGRAL_TYPE_P (type)
+ && INTEGRAL_TYPE_P (TREE_TYPE (@4))
+ && TREE_CODE (TREE_TYPE (@4)) != BOOLEAN_TYPE
+ && INTEGRAL_TYPE_P (TREE_TYPE (@5))
+ && (TYPE_PRECISION (TREE_TYPE (@4)) >= TYPE_PRECISION (type)
+ || !TYPE_UNSIGNED (TREE_TYPE (@4))))
+ (cond (cmp @2 @3) @1 @0)))
I was going to suggest
(cond @5 @1 @0)
and possibly replacing (cmp@5 @2 @3) with truth_valued_p@5, before
remembering that COND_EXPR embeds the comparison, and that not
transforming when we don't see the comparison is likely on purpose. Plus,
if @5 was in a signed 1-bit type, it may look more like -1 than 1 and
break the transformation (is that forbidden as return type of a
comparion?).
--
Marc Glisse
