> I'm trying to add a hook for aligning vectors for loads.
>
> I'm using the altivec rs6000 code as a baseline.
>
> However, the instruction is like the iwmmxt_walign instruction in the
> ARM port; it takes
> a normalish register and uses the bottom bits... it doesn't use a
> full-width vector.
>
> GCC complains when my builtin pointed to by
> TARGET_VECTORIZE_BUILTIN_MASK_FOR_LOAD yields a QImode result, because
> it has no way of converting that to the vector moe it is expecting.  I

Looks like it's a bug in the vectorizer - we treat both the return value of
the mask_for_load builtin, and the 3rd argument to the realign_load stmt
(e.g. Altivec's vperm), as variables of type 'vectype', instead of
obtaining the type from the target machine description. All we need to care
about is that these two variables have the same type. I'll look into that

dorit

> think the altivec side would have a similar problem, as the expected
> RTX output RTX is:
>
> (reg:V8HI 131 [ vect_var_.2540 ])
>
> but it changes that to:
>
> (reg:V16QI 160)
>
> for the VLSR instruction.  V16QImode is what VPERM expects, and I
> think since V8HI and V16QI mode are the same size everyone is happy.
>
> Is there a way to tell GCC what the type of the
> TARGET_VECTORIZE_BUILTIN_MASK_FOR_LOAD should be?  Looking at
> http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gccint/Addressing-Modes.
> html#Addressing-Modes
> it reads like it must merely match the last operand of the
> vec_realign_load_<mode> pattern.
>
> --
> Why are ``tolerant'' people so intolerant of intolerant people?

Reply via email to