Re: [LNO, mainline] Remember rs6000 builtins decls

[Geoff Keating <geoffk at geoffk dot org>]

Devang Patel <dpatel@apple.com> writes:

> On Jun 6, 2004, at 6:11 PM, Richard Henderson wrote:
> 
> > On Sun, Jun 06, 2004 at 11:28:09PM +0300, Ayal Zaks wrote:
> >> Well, take loads/stores from/to unaligned memory addresses as an
> >> example.
> >> The vectorizer needs to know if the target supports such
> >> operations, and if
> >> so at what cost. Note that such a cost might be amortized across
> >> several
> >> loads/stores, and could determine if the entire loop is worth
> >> vectorizing
> >> or not.
> >
> > And you get this from tables of FUNCTION_DECLs ... how?
> 
> In Altivec's case, when vec_add() is encountered instead of
> generating vector trees, FE adds direct call to Altivec builtins.

That would be a bug.  Why can't it just generate PLUS?  Having a
function call will make the tree-ssa optimisers much less useful.

> And we want to use this table in rs6000 taget hook to directly get
> access to builtin Altivec permute operations to adjust alignment.

For permute operations, it seems to me that rs6000 is not the only
platform that has them, so I do not see why it should be
target-specific.  In fact, I expect that the vectorizer is going to
need to know how to generate every kind of permutation, whether the
hardware has it or not, and the only question is how much it will
cost.

-- 
- Geoffrey Keating <geoffk@geoffk.org>