[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 <jakub at gcc dot gnu.org> 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 <jakub at gcc dot gnu.org> ---
-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 <vect__4.16_103 == vect_cst__109,
vect__6.19_106, vect_iftmp.20_108>;
+  _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 <vect__4.16_103 == { 0.0, 0.0 },
vect__6.19_106, vect_iftmp.20_108>;

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.