This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Type yielded by TARGET_VECTORIZE_BUILTIN_MASK_FOR_LOAD hook?
- From: Dorit Nuzman <DORIT at il dot ibm dot com>
- To: "Erich Plondke" <eplondke at gmail dot com>, gcc at gcc dot gnu dot org
- Cc: Ira Rosen <IRAR at il dot ibm dot com>
- Date: Sat, 16 Sep 2006 20:34:51 +0300
- Subject: Re: Type yielded by TARGET_VECTORIZE_BUILTIN_MASK_FOR_LOAD hook?
"Erich Plondke" <eplondke@gmail.com> wrote on 16/09/2006 05:26:50 PM:
> On 9/16/06, Dorit Nuzman <DORIT@il.ibm.com> wrote:
> > 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
>
> When I undefined mask_for_load, I got a pointer type as my 3rd
> argument in the realign_load statement... so I made the expander there
> generate the extra code sequence for setting up the shift value.
>
right - if a target doesn't define a mask_for_load, the default is to pass
realign_load a pointer to the location accessed in each iteration.
> Actually, I wonder why this wasn't done for altivec... couldn't you
> make the realign_load expander generate the lvsr? Or does the
> mask_for_load help it to be eliminated when the offset is
> loop-invariant (which would help here also)?
exactly - the mask_for_load stuff is loop invariant and takes place before
the loop (as opposed to the default solution when mask_for_load is not
defined).
dorit
> Or is it just that it
> takes a whole addressing mode instead of a single address?