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: Dorit Naishlos <DORIT at il dot ibm dot com>
- To: Richard Henderson <rth at redhat dot com>
- Cc: Ayal Zaks <ZAKS at il dot ibm dot com>, Andrew Pinski <pinskia at physics dot uc dot edu>, Devang Patel <dpatel at apple dot com>, gcc-patches at gcc dot gnu dot org, Geoff Keating <geoffk at geoffk dot org>
- Date: Wed, 9 Jun 2004 15:56:12 +0300
- Subject: Re: [LNO, mainline] Remember rs6000 builtins decls
I think we all agree that introducing new tree codes is better than using
builtins.
The only (potential) reason for not using tree codes is for operations that
are not general, and/or which are complicated in the sense that even if
they had a tree-code it would probably be treated by the optimizers like a
black-box which hides a certain functionality, much like a builtin
function. At least that was my assumption... would the tree-level
optimizers be able to handle such tree-codes (which semantics they don't
"understand") any better than builtins?
I think the question here is where we draw the line between operations that
qualify to have their own tree-codes, and those that don't. You seem to
suggest that all operations qualify to have a tree-code. We were not sure
that adding so many new tree-code would be acceptable, and therefore our
approach was:
(1) operations that are general enough, and which semantics are simple
enough (i.e. - the optimizers can actually do something with them) should
definitely have a tree-code.
(2) operations which we're not sure whether they qualify to have a
tree-code (because they are less general or represent low level details or
are relatively complicated) would be expressed using builtins, and possibly
replaced with tree-codes later on, after people agree that these tree-codes
deserve to exist. I guess we can skip directly to propose these new
tree-codes then...
dorit
Richard Henderson
<rth@redhat.com> To: Ayal Zaks/Haifa/IBM@IBMIL
Sent by: cc: Andrew Pinski <pinskia@physics.uc.edu>, Devang Patel <dpatel@apple.com>,
gcc-patches-owner@ gcc-patches@gcc.gnu.org, Dorit Naishlos/Haifa/IBM@IBMIL, Geoff Keating
gcc.gnu.org <geoffk@geoffk.org>
Subject: Re: [LNO, mainline] Remember rs6000 builtins decls
08/06/2004 22:46
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~