On Wed, Aug 17, 2011 at 11:49 AM, Richard Guenther
<richard.guent...@gmail.com> wrote:
>>> Hm, ok ... let's hope we can sort-out the backend issues before this
>>> patch goes in so we can remove this converting stuff.
>>
>> Hm, I would hope that we could commit this patch even with this issue,
>> because my feeling is that this case would produce errors on all the
>> other architectures as well, as VEC_COND_EXPR is the feature heavily
>> used in auto-vectorizer. So it means that all the backends must be
>> fixed. And another argument, that this conversion is harmless.
>
> It shouldn't be hard to fix all the backends. And if we don't do it now
> it will never happen. I would expect that the codegen part of the
> backends doesn't need any adjustments, just the patterns that
> match what is supported.
>
> Uros, can you convert x86 as an example? Thus, for
>
> (define_expand "vcond<mode>"
> [(set (match_operand:VF 0 "register_operand" "")
> (if_then_else:VF
> (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" "")))]
> "TARGET_SSE"
> {
> bool ok = ix86_expand_fp_vcond (operands);
> gcc_assert (ok);
> allow any vector mode of the same size (and same number of elements?)
> for the vcond mode and operand 1 and 2? Thus, only restrict the
> embedded comparison to VF?
I am a bit late to this discussion, but I see no problem for the
backend to relax this restriction. I will look into it.
Uros.
