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. 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. Uros.
