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: Geoff Keating <geoffk at geoffk dot org>
- To: Dorit Naishlos <DORIT at il dot ibm dot com>
- Cc: Devang Patel <dpatel at apple dot com>, gcc-patches at gcc dot gnu dot org, Richard Henderson <rth at redhat dot com>, Ayal Zaks <ZAKS at il dot ibm dot com>, Andrew Pinski <pinskia at physics dot uc dot edu>
- Date: Wed, 9 Jun 2004 10:17:16 -0700
- Subject: Re: [LNO, mainline] Remember rs6000 builtins decls
- References: <OF180F809D.3524D5F4-ONC2256EAE.0040C933-C2256EAE.0047106B@il.ibm.com>
On 09/06/2004, at 5:56 AM, Dorit Naishlos wrote:
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...
I would suggest that the criteria should be "operations which the
optimisers need to deal with should not be a builtin". In particular,
anything that the vectorizer can generate should be fully represented
as trees.
I think this is just another way of saying what you said above, which
is that if the optimiser is going to treat it as a 'black box' then it
might as well be a builtin function. (Such operations are pretty
rare---even if the exact details of the operation are complicated,
fold() can be taught to do it.)