[PATCH] Add VEC_COND_EXPR node

[Roger Sayle]

On Wed, 22 Sep 2004, Richard Henderson wrote:
> On Tue, Sep 21, 2004 at 08:17:21PM -0600, Roger Sayle wrote:
> > My apologies if these issues were considered and resolved when this
> > topic was discussed on the gcc list, but unfortunately keeping up
> > with gcc-patches is hard enough.  Has anyone considered VEC_LT_EXPR,
> > VEC_GE_EXPR, VEC_EQ_EXPR, etc...?
>
> No, we hadn't discussed that.  I had sort of been hoping to
> avoid it too...  Would a <vector boolean n> result type for
> the EQ_EXPR make you happy?

Sure.  I was just concerned we might be silently generating incorrect
code for the corner cases.   If you believe that this isn't likely to
be a problem, I'm happy for the time being to avoid discussing it too.

The changes to support vector_boolean_n should be mostly mechanical
once we teach fold_convert to convert "boolean" -> vector_boolean_n,
as most optimizations really are safe, and do the right thing.

	A = VEC_COND (X == X, C, B)
=>	A = VEC_COND (fold_convert (T, true), C, B)
=>	A = C

for example, I think its only fold_relational_const that could be
a problem, and adding support for VECTOR_CST op VECTOR_CST that
distinguishes where TREE_CODE (return_type) == VECTOR_TYPE should
be enough to resolve any ambiguity.

Do targets typically support vector_boolean_constants other than
all true or all false, for example to support scatter/gather
operations?  It could be arranged either that the only
vector_boolean_constants we support are all-true and all-false,
and simply avoid constant folding other VECTOR_CST comparisons
at compile-time.  Less ideal, would be to initially disable
folding of any relational/equality operator with a vector type.

Sorry for any inconvenience,

Roger
--