Re: Vector Comparison patch

[Artem Shinkarov <artyom dot shinkaroff at gmail dot com>]

> Yes. ?I think the backends need to handle optimizing this case,
> esp. considering targets that do not have instructions to produce
> a {-1,...}/{0,...} bitmask from a comparison but produce a vector
> of condition codes. ?With using vec0 > vec1 ? {-1...} : {0,...} for
> mask = vec0 > vec1; we avoid exposing the result kind of
> vector comparisons.
>
> It should be easily possible for x86 for example to recognize
> the -1 : 0 case.

Ok, I am fine with this approach. Ho could we check if vector
comparison returns {-1..}/{0..} or something else. If I can check
that, I could adjust expand_vec_cond_exrp, and get rid of the hook.

> Yes, and I think the fix is in the backends. ?I still think we have to
> sort out the best building blocks we want the targets to expose.
> Currently we only have the vectorizer vcond patterns which should
> be enough to get the C language support implemented. ?After that
> we should concentrate on generating efficient code for all variants.

Ok, see my above comment.

> Yeah, well. ?That's really a question for language lawyers ;) ?I agree
> that it would be nice to have mask ? val0 : val1 behave "the same"
> for scalars and vectors. ?The question is whether for vectors you
> define it on the bit-level (which makes it equal to (mask & val0) |
> (~mask & val1))
> or on the vector component level. ?The vector component level
> is probably what people would expect.
>
> Which means we have to treat mask ? val0 : val1 as
> mask != {0,...} ? val0 : val1.

> I'd use != {0,0,...} as eventually a zero vector is cheaper to construct
> and it supports the scalar ?: semantics - whenever the mask element
> is non-zero it's true.

Ok, I am fine with x != {0,...}, I can adjust it in both cases.


Artem.