Re: [tree-ssa-branch] Optimizing non-SIMPLE trees

[Diego Novillo <dnovillo at redhat dot com>]

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
function).

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?


Diego.