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: Ayal Zaks <ZAKS at il dot ibm dot com>
- To: Andrew Pinski <pinskia at physics dot uc dot edu>
- Cc: Devang Patel <dpatel at apple dot com>, gcc-patches at gcc dot gnu dot org, Dorit Naishlos <DORIT at il dot ibm dot com>
- Date: Sun, 6 Jun 2004 23:28:09 +0300
- Subject: Re: [LNO, mainline] Remember rs6000 builtins decls
On Jun 5, 2004, at 13:38, Andrew Pinski wrote:
But why use the builtins, can you just define some generic trees which does
the same thing as the target builtins does today and have expand expand
them
to RTL which the back-end understands? This is how the generic vector stuff
works and how the auto-vectorizing should work also os it is more generic
and
easier to add/maintain the back-ends.
On Jun 5, 2004, at 13:43, Andrew Pinski wrote:
But you can found that out not by builtins but by optab tables checking
if they are available like expand does when converting from trees to RTL.
I would assume this is more generic/easier to maintain than having to
ask the back-end for a builtin function.
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.
Ayal.