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.
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. 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.
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.
Thanks for the comments,
--
Marc Glisse
