On Fri, Sep 28, 2012 at 6:55 PM, Marc Glisse <marc.gli...@inria.fr> wrote: > On Fri, 28 Sep 2012, Richard Guenther wrote: > >> On Fri, Sep 28, 2012 at 12:42 AM, Marc Glisse <marc.gli...@inria.fr> >> wrote: >>> >>> Hello, >>> >>> I have been experimenting with generating VEC_COND_EXPR from the >>> front-end, >>> and these are just a couple things I noticed. >>> >>> 1) optabs.c requires that the first argument of vec_cond_expr be a >>> comparison, but verify_gimple_assign_ternary only checks >>> is_gimple_condexpr, >>> like for COND_EXPR. In the long term, it seems better to also allow >>> ssa_name >>> and vector_cst (thus match the is_gimple_condexpr condition), but for now >>> I >>> just want to know early if I created an invalid vec_cond_expr. >> >> >> optabs should be fixed instead, an is_gimple_val condition is implicitely >> val != 0. > > > For vectors, I think it should be val < 0 (with an appropriate cast of val > to a signed integer vector type if necessary). Or (val & highbit) != 0, but > that's longer.
I don't think so. Throughout the compiler we generally assume false == 0 and anything else is true. (yes, for FP there is STORE_FLAG_VALUE, but it's scope is quite limited - if we want sth similar for vectors we'd have to invent it). >> The tree.[ch] and gimple-fold.c hunks are ok if tested properly, the >> tree-ssa-forwprop.c idea of using TREE_TYPE (cond), too. > > > Ok, I will retest that way. > > >> I don't like the tree-cfg.c change, instead re-factor optabs.c to >> get a decomposed cond for vector_compare_rtx and appropriately >> "decompose" a non-comparison-class cond in expand_vec_cond_expr. > > > So vector_compare_rtx will take as arguments rcode, t_op0, t_op1 instead of > cond. Yes. > And in expand_vec_cond_expr, if I have a condition, I pass its > elements to vector_compare_rtx, and otherwise I use 0 and the code for > LT_EXPR as the other arguments. Yes, but NE_EXPR and 0 (see above). > >> If we for example have >> >> predicate = a < b; >> x = predicate ? d : e; >> y = predicate ? f : g; >> >> we ideally want to re-use the predicate computation on targets where >> that would be optimal (and combine should be able to recover the >> case where it is not). > > > That I don't understand. The vcond instruction implemented by targets takes > as arguments d, e, cmp, a, b and emits the comparison itself. I don't see > how I can avoid sending to the targets both (d,e,<,a,b) and (f,g,<,a,b). > They will notice eventually that a<b is computed twice and remove one of the > two, but I don't see how to do that in optabs.c. Or I can compute x = a < b, > use x < 0 as the comparison passed to the targets, and expect targets (those > for which it is true) to recognize that < 0 is useless in a vector condition > (PR54700), or is useless on a comparison result. But that's a limitation of how vcond works. ISTR there is/was a vselect instruction as well, taking a "mask" and two vectors to select from. At least that's how vcond works internally for some sub-targets. Richard. > Thanks for the comments, > > -- > Marc Glisse
