This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [LNO, mainline] Remember rs6000 builtins decls
- From: Richard Henderson <rth at redhat dot com>
- To: Ayal Zaks <ZAKS at il dot ibm dot com>
- Cc: Andrew Pinski <pinskia at physics dot uc dot edu>, Devang Patel <dpatel at apple dot com>, gcc-patches at gcc dot gnu dot org, Dorit Naishlos <DORIT at il dot ibm dot com>, Geoff Keating <geoffk at geoffk dot org>
- Date: Tue, 8 Jun 2004 12:46:56 -0700
- Subject: Re: [LNO, mainline] Remember rs6000 builtins decls
- References: <OF96536E1C.CD67240A-ONC2256EAD.0066394A-C2256EAD.006A8A73@il.ibm.com>
On Tue, Jun 08, 2004 at 10:23:42PM +0300, Ayal Zaks wrote:
> >And you get this from tables of FUNCTION_DECLs ... how?
>
> By not hiding inside a single generic tree something (e.g.
> load-from-unaligned-address) that will later expand into
> several builtins, some of which could be combined/amortized
> /moved-out-of-loops iff known to the vectorizer.
> I think Dorit talked about some of these options at the summit.
Yes, but builtins do NOT help. Indeed, they'll hurt more.
Your mistake is assuming that we can only have a single
tree that does a complete unaligned load or store.
Indeed, I would assume the opposite -- the exception is going
to be the target that can do unaligned acceses. The rule is
going to be two loads followed by some sort of merge operation.
> But *until tree codes are defined* for some of the exotic (yet
> critical) builtins that we want to use, I think our only option
> is to use target hooks that emit builtin FUNCTION_DECLs.
No, your other option is to design and propose tree codes.
It shouldn't take too long to survey the extant processors
that support vector operations and catalogue the available
methods for forming unaligned load/store, then choose some
representative operations or concepts to apply.
r~