On Mon, 9 Sep 2019, Martin Liška wrote: > On 9/9/19 3:10 PM, Marc Glisse wrote: > > On Mon, 9 Sep 2019, Martin Liška wrote: > > > >> I'm sending slightly updated version of the patch where we > >> need to properly select type in maybe_fold_comparisons_from_match_pd > >> function for the created SSA_NAMEs. We can be called for a VECTOR_TYPE > >> and so that we can't return a boolean_type_node. > > > > + tree type = TREE_TYPE (op1a); > > + if (TREE_CODE (type) != VECTOR_TYPE) > > + type = boolean_type_node; > > > > Don't you need build_same_sized_truth_vector_type or something, for > > instance with AVX512? > > > > Also, IIRC EQ_EXPR for vectors can return either a vector or a boolean. I > > don't know if we can end up here with both versions, but if we can, > > guessing the type could be dangerous. Would it be hard to add a type > > argument to those functions and delegate this to the caller? Any better > > idea (maybe this is already safe and I am just missing it)? > > Richi can you help us here? I'm not sure what guarantees do we have here in > GIMPLE?
Oops, I missed this hunk - the caller needs to pass this down, but at least from the ifcombine use we are always coming from a if (a CMP b) context and thus a boolean_type_node result type. For the reassoc case there's indeed nothing preventing from vector typed comparisons sneaking in here, likewise recursion via or_var_with_comparison_1 might run into vectors. Thus the toplevel interface has to pass down the (common) type of the two comparisons. Richard.
