[Bug target/89570] [9 Regression] ICE in prepare_cmp_insn, at optabs.c:4001

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89570

--- Comment #3 from Jakub Jelinek  ---
At the minimum guarding those simplifications with something like
expand_vec_cmp_expr_p test for @0 if we can figure out mask type somehow (what
would IFN_COND_* need), and a check whether IFN_COND_* is supported at all.

[Bug target/89570] [9 Regression] ICE in prepare_cmp_insn, at optabs.c:4001

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89570

--- Comment #2 from Jakub Jelinek  ---
Or perhaps as an alternative, we shouldn't use the match.pd code here to tweak
the conditions of VEC_COND_EXPRs exactly because the conditions themselves
might be valid solely in VEC_COND_EXPR's first argument and not as standalone
stmt, and just use some C helper from the match.pd rule or something to deal
with that instead.

[Bug target/89570] [9 Regression] ICE in prepare_cmp_insn, at optabs.c:4001

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89570

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-04
 CC||jakub at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org,
   ||rsandifo at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
-fno-tree-dce considered harmful (as in many cases).
Seems in this case match.pd invoked during forwprop4 (after generic vector
lowering) creates statements that don't have hw support.

 (simplify
  (vec_cond @0 @1 (view_convert? (uncond_op@4 @2 @3)))
  (with { tree op_type = TREE_TYPE (@4); }
   (if (element_precision (type) == element_precision (op_type))
(view_convert (cond_op (bit_not @0) @2 @3 (view_convert:op_type @1)))
and are dead.
The dse3 to forwprop4 changes are:
-  vect_iftmp.20_108 = vect__6.19_106 * vect_cst__107;
+  vect_iftmp.20_108 = vect__6.19_106 * { 5.0e-1, 5.0e-1 };
   iftmp.5_28 = _14 * 5.0e-1;
-  vect_iftmp.21_110 = VEC_COND_EXPR ;
+  _34 = vect__4.16_103 == { 0.0, 0.0 };
+  _1 = vect__4.16_103 != { 0.0, 0.0 };
+  vect_iftmp.21_110 = VEC_COND_EXPR ;

No target other than aarch64 has the IFN_COND_* support so far (though I bet
AVX512F could be a good candidate for that), so for the other targets the above
match.pd pattern just creates garbage that with -fno-tree-dce isn't even
removed.
Shouldn't that match.pd simplification be a) restricted to targets that
actually have some IFN_COND_*, so that it doesn't do useless work elsewhere b)
even if it fails, clean up the temporaries it created while processing the
(bit_not @0) if it fails?

Guess this has been introduced with r260710.

[Bug target/89570] [9 Regression] ICE in prepare_cmp_insn, at optabs.c:4001

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89570

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
  Component|middle-end  |target