Hi,
In PR123268 we transform x * { 0 or 1, 0 or 1, ... } into
x & { 0 or -1, 0 or -1, ...} which is a match.pd pattern.
We start out with
vect_b_28.48_48 = .COND_LEN_MUL ({ -1, -1, -1, -1 }, a, b, { 0.0, 0.0, 0.0,
0.0 }, 4, 0);
and simplify to
_67 = .COND_LEN_AND ({ -1, -1, -1, -1 }, _60, { 4294967295, 0, 0, 0 }, { 0.0,
0.0, 0.0, 0.0 }, 4, 0);
where the operation type is int but the else value (that we just copied
over from the original op) is still float.
In order to catch that, this patch checks if the operation type and the
else value type are compatible while reassembling the conditional
operation.
Bootstrapped and regtested on x86, power10, and aarch64.
Regtested on riscv64.
Regards
Robin
gcc/ChangeLog:
* gimple-match-exports.cc (convert_conditional_op): Check if
orig_op->type and type of else value match.
---
gcc/gimple-match-exports.cc | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/gcc/gimple-match-exports.cc b/gcc/gimple-match-exports.cc
index 555e8a967a0..9f08f86dabe 100644
--- a/gcc/gimple-match-exports.cc
+++ b/gcc/gimple-match-exports.cc
@@ -187,6 +187,13 @@ convert_conditional_op (gimple_match_op *orig_op,
if (!else_value)
else_value = targetm.preferred_else_value (ifn, orig_op->type,
num_ops, orig_op->ops);
+
+ /* Some patterns convert operand types, e.g. from float to int.
+ If we had a real else value before (e.g. float) it won't match
+ the type. Check that here. */
+ if (!types_compatible_p (orig_op->type, TREE_TYPE (else_value)))
+ return false;
+
new_op->ops[num_ops + 1] = else_value;
if (orig_op->cond.len)
{
--
2.52.0
