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.