This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH, vectorizer]: Take3: Vectorize FP conversions


Uros Bizjak <ubizjak@gmail.com> wrote on 22/04/2007 22:30:59:

> H. J. Lu wrote:
> > On Sun, Apr 22, 2007 at 05:56:35PM +0200, Uros Bizjak wrote:
> >
> >> Dorit Nuzman wrote:
> >>
> >>
> >>> I'm sorry for not raising the following question before (didn't
> occur to me
> >>> until now): Do we really need to duplicate the vec_unpack optab
> for floats,
> >>> rather than reusing the vec_unpacks for both ints and floats, just
like
> >>> optabs smul,smin,smax? (either way is fine with me, just a question
of
> >>> general optab policy in gcc)
> >>>
> >>>
> >> Hm, I never noticed that TYPE_UNSIGNED also operates correctly on
float
> >> types.
> >>
> >> Due to this, this revision includes your suggestion to name FP
patterns
> >> vec_unpacks_*.
> >>
> >>
> >
> > Can you also add integer vector extensions available in SSE4.1? That is
> > SSE4.1 can do things like
> >
> >   [(set (match_operand:V2DI 0 "register_operand" "=x")
> >         (zero_extend:V2DI
> >           (vec_select:V2HI
> >             (match_operand:V8HI 1 "nonimmediate_operand" "xm")
> >             (parallel [(const_int 0)
> >                        (const_int 1)]))))]
> >
> Currently infrastructure only supports extensions, where one vector with
> N elements of size S is extended into two vectors with N elements of
> size 2*S, and truncations where two vectors with N elements of size S
> are truncated to one vector with N elements of size S/2. It looks to me
> that above pattern is not yet supported.
>

Indeed, the pack/unpack patterns that we have introduced so far express
conversion between types that are exactly twice the size of one another.
The intention was to extend the type_promotion/demotion vectorization
functions to use these building blocks recursively when we have e.g. a
short<-->long conversion:

   v4si_1 = vec_unpack_hi (v8hi_1)
   v4si_2 = vec_unapck_lo (v8hi_1)

   v2di_1 = vec_unapck_hi (v4si_1)
   v2di_2 = vec_unapck_lo (v4si_1)
   v2di_3 = vec_unapck_hi (v4si_2)
   v2di_4 = vec_unapck_lo (v4si_2)

We'd need to add a way to expose the new vector unpacking idioms (hi->di),
and teach the vectorizer to use them.

dorit

> Uros.
>
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]