Re: vec_cond_expr adjustments

[Marc Glisse <marc dot glisse at inria dot fr>]

On Mon, 8 Oct 2012, Richard Guenther wrote:

> > VEC_COND_EXPR is more complicated. We could for instance require that it
> > takes as first argument a vector of -1 and 0 (thus <0, !=0 and the neon
> > thing are equivalent). Which would leave to decide what the expansion of
> > vec_cond_expr passes to the targets when the first argument is not a
> > comparison, between !=0, <0, ==-1 or others (I vote for <0 because of
> > opencl). One issue is that targets wouldn't know if it was a dummy
> > comparison that can safely be ignored because the other part is the result
> > of logical operations on comparisons (thus composed of -1 and 0) or a
> > genuine comparison with an arbitrary vector, so a new optimization would be
> > needed (in the back-end I guess or we would need an alternate instruction to
> > vcond) to detect if a vector is a "signed boolean" vector.
> > We could instead say that vec_cond_expr really follows OpenCL's semantics
> > and looks at the MSB of each element. I am not sure that would change much,
> > it would mostly delay the apparition of <0 to RTL expansion time (and thus
> > make gimple slightly lighter).
>
> I think we should delay the decision on how to optimize this.  It's indeed
> not trivial and the GIMPLE middle-end aggressively forwards feeding
> comparisons into the VEC_COND_EXPR expressions already (somewhat
> defeating any CSE that might be possible here) in forwprop.

Thanks for going through the long email :-)

What does that imply for the first argument of VEC_COND_EXPR? Currently, 
the expander asserts that it is a comparison, but that is not reflected in 
the gimple checkers.

If we document that VEC_COND_EXPR takes a vector of -1 and 0 (which is the 
case for a comparison), I don't think it prevents from later relaxing that 
to <0 or !=0. But then I don't know how to handle expansion when the 
argument is neither a comparison (vcond) nor a constant (vec_merge? I 
haven't tried but that should be doable), I would have to pass <0 or !=0 
to the target. So is the best choice to document that VEC_COND_EXPR takes 
as first argument a comparison and make gimple checking reflect that? 
(seems sad, but at least that would tell me what I can/can't do)

By the way, since we are documenting comparisons as returning 0 and -1, 
does that bring back the integer_truep predicate?

--
Marc Glisse