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.
>
> 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.
I wonder, if we make vcond being able to FAIL (well, it would fail for
invalid input only, like mismatching mode size), if patches along
Index: gcc/config/i386/sse.md
===================================================================
--- gcc/config/i386/sse.md (revision 178209)
+++ gcc/config/i386/sse.md (working copy)
@@ -1406,13 +1406,13 @@ (define_insn "<sse>_ucomi"
(set_attr "mode" "<MODE>")])
(define_expand "vcond<mode>"
- [(set (match_operand:VF 0 "register_operand" "")
- (if_then_else:VF
+ [(set (match_operand 0 "register_operand" "")
+ (if_then_else
(match_operator 3 ""
[(match_operand:VF 4 "nonimmediate_operand" "")
(match_operand:VF 5 "nonimmediate_operand" "")])
- (match_operand:VF 1 "general_operand" "")
- (match_operand:VF 2 "general_operand" "")))]
+ (match_operand 1 "general_operand" "")
+ (match_operand 2 "general_operand" "")))]
"TARGET_SSE"
{
bool ok = ix86_expand_fp_vcond (operands);
would be enough to make it accept V4SF < V4SF ? V4SI : V4SI with
target mode V4SI. The expander code doesn't seem to care about
the modes of op1/2 too much.
Richard.
> Uros.
>
