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

[Jan Hubicka <jh at suse dot cz>]

> 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 see. Some of the md expanders do clever things when operands are known
to be constants.  This is not only the case of string functions but also
other stuff (like shifting, double word arithmetics etc.)
In the case simplifier loads constants to temporaries first, you lose
the performance.  I guess it is a must to constant propagate just before
RTL generation, that should fix the problem.

Similary I think it is neccesary to put in the memories when used
exactly once, that should solve builtin_stdarg.
> 
> 
> > 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?
I don't think we have some mighty builtins, like stdarg_start in target
specific way, so it is safe to handle them as function in all cases I am
aware of.  If we start doing so, we won't introduce the nasty stuff and
over with better design I believe.

Honza
> 
> 
> Diego.