This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Vector Comparison patch
On Wed, Aug 17, 2011 at 11:49 AM, Richard Guenther
<richard.guenther@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.