This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Vector Comparison patch
On Mon, Aug 22, 2011 at 9:50 PM, Uros Bizjak <ubizjak@gmail.com> wrote:
> On Mon, Aug 22, 2011 at 5:34 PM, Richard Guenther
> <richard.guenther@gmail.com> wrote:
>
>>> In this case it is simple to analyse that a is a comparison, but you
>>> cannot embed the operations of a into VEC_COND_EXPR.
>>
>> Sure, but if the above is C source the frontend would generate
>> res = a != 0 ? v0 : v1; initially. ?An optimization pass could still
>> track this information and replace VEC_COND_EXPR <a != 0, v0, v1>
>> with VEC_COND_EXPR <a, v0, v1> (no existing one would track
>> vector contents though).
>>
>>> Ok, I am testing the patch that removes hooks. Could you push a little
>>> bit the backend-patterns business?
>>
>> Well, I suppose we're waiting for Uros here. ?I hadn't much luck with
>> fiddling with the mode-iterator stuff myself.
>
> It is not _that_ trivial change, since we have ix86_expand_fp_vcond
> and ix86_expand_int_vcond to merge. ATM, FP version deals with FP
> operands and vice versa. We have to merge them somehow and split out
> comparison part that handles FP as well as integer operands.
Yeah, I tried to keep it split in fp and int compare variants but allow
the result mode and the 2nd and 3rd operand modes to vary differently
but failed to build a mode iterator that would do this... OTOH I'm not
sure how merging fp and int compare modes would simplify things here.
> I also don't know why vcond is not allowed to FAIL... probably
> middle-end should be enhanced for a fallback if some comparison isn't
> supported by optab.
The vectorizer currently uses the optab presence to verify if the
target supports a given vec-cond-expr. I'm not sure if we can
make its test more finegrained easily.
Richard.
>
> Uros.
>