On Mon, Aug 22, 2011 at 9:50 PM, Uros Bizjak <ubiz...@gmail.com> wrote: > On Mon, Aug 22, 2011 at 5:34 PM, Richard Guenther > <richard.guent...@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. >