"Erich Plondke" <[EMAIL PROTECTED]> wrote on 16/09/2006 05:26:50 PM:
> On 9/16/06, Dorit Nuzman <[EMAIL PROTECTED]> 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?
