This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa-branch] Optimizing non-SIMPLE trees
On Fri, 09 Aug 2002, Richard Henderson wrote:
> On Fri, Aug 09, 2002 at 10:09:37AM -0400, Diego Novillo wrote:
> > The simplifier refuses to simplify the call to strncmp() because
> > it contains at least one constant argument. It does this to
> > avoid tricking the code generator into not outputting a builtin
> > call when all the arguments are constant.
> This is bogus.
string-opt-8.c fails for this exact reason. If we simplify calls
to strncmp, whatever code that converts strncmp into a builtin
call fails to match the builtin and then a libcall is generated.
> > Clearly, the simplifier could be a bit smarter in this case, but
> > the point remains that we will many times refuse to simplify a
> > builtin or other special trees. The question is now, how do we
> > tell the optimizers to keep their hands off these trees?
> No, this is not clear. You'd be complicating the optimizers for
> no reason whatsoever.
Just the other day we were talking about trees that would need to
be passed unsimplified. You have to tell the optimizers that
they cannot look *into* those trees. MD builtins have this
problem as well, we can't really simplify those trees as we don't
know what the backend might expect.
> The correct solution here is to expand builtin functions *after*
> constant propagation. Then we get nice builtin expansion when
> the user hasn't written something convenient up front.
Builtin functions are always expanded after constant propagation.
Aren't builtins expanded as part of the tree->RTL expansion?
That's after tree CCP.
> Of course afterwards you get to re-do the propagation, since we
> may well have generated new constants.
Will fold() deal with __builtin_strncmp if all its arguments are