This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa-branch] Optimizing non-SIMPLE trees
On Sat, 2002-08-10 at 18:12, Jan Hubicka wrote:
> > On Sat, 2002-08-10 at 17:31, Richard Henderson wrote:
> > > > 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.
> > >
> > > You won't be incorrect if you treat them like a regular
> > > function call.
> > >
> > That's exactly what we're doing now. Trees that cannot be simplified
> > are flagged TF_NOT_SIMPLE. This causes the reference finder to create
> > definitions for all the symbols referenced by the expression. Safe and
> > easy.
> Is this necesary? The builtins behave like real C functions, so they
> don't modify their arguments.
No. It started being a cheap way out, but it's becoming to be a
horrendous idea (serves me right for going down this path). It all
started when the simplifier had problems with __builtin_stdarg_start
(which expects its argument to be the last parameter to the current
But then, we also ran into problems when the simplifier replaced
arguments to some of the __builtin_str* functions. When simplified, the
compiler would stop matching the builtin and emit a libcall. IIRC,
builtins defined in .md files had similar problems.
> I would believe that it is wortwhile to invest energy into simplifying
> everything around to avoid creating of tons of special cases like we
> have in RTL.
Yes. I should do the right thing and see why simplification confuses
some builtins. The question is, what about target-defined builtins?
Should the simplifier leave them alone?