Re: [tree-ssa-branch] simplify builtins

[Daniel Berlin <dberlin at dberlin dot org>]

On Sat, 29 Jun 2002, Diego Novillo wrote:

> On Sat, 29 Jun 2002, Aldy Hernandez wrote:
> 
> > On Sat, Jun 29, 2002 at 03:55:39PM -0400, Diego Novillo wrote:
> > > On Sat, 29 Jun 2002, Aldy Hernandez wrote:
> > > 
> > > > what's the slowness factor in the compiler now?
> > > > 
> > > Bootstrap times are roughly 2x.  Yes, it's disgraceful.
> > 
> > have you benchmarked this to find out where most of the time is being
> > spent?
> > 
> Only once I ran the stage3 compiler under oprofile.
> 
> > is it in the simplification or in the ssa building?  or both?
> > 
> Neither.  The SSA and simplification routines didn't even make it
> to the top 20 functions.  The top two were cse_insn and
> for_each_rtx.  My wildly uninformed guess is that simplification
> is causing the creation of lots of junk RTL.
> 
> > are we running ssa on the simplified trees only?
> >
> Yes.
> 
> > are we doing the ssa-on-rtl thing as well?
> > 
> Only if -fssa is enabled.
> 
> > *puts speculation hat on*
> > 
> > hmmmm, this seems like something worth looking into.  i doubt anyone's
> > going to be too inclined to use these optimizations if there's a 2X
> > slowdown.
> > 
> Absolutely.
> 
> > perhaps when we start disabling rtl optimizers and replacing them with
> > simple-tree optimizers we can see an increase in speed?  or at least
> > a decrease that's not as bad :)
> > 
> Yes and no.  In the future we will have replaced some RTL passes,
> but others we will need to keep at both tree and RTL.
> 
> > now that we have everything simpliable for C, perhaps we can implement
> > one entire optimization pass (constant propagation or PRE ?) entirely
> > on trees and disable the rtl counterparts.  that should give us an idea
> > of how bad things are going to look ;-).
> > 
> Daniel implemented the beginnings of PRE on trees in
> tree-ssa-pre.c.  

I'm not sure it should be characterized as "beginnings", considering it 
does as much as our current PRE already.
:)
Though, compared to what it *will* do, it's beginnings.

>I am working on dead-code and const-prop.  We 
> should probably implement a bunch of the dominator based and
> control flow optimizations.  But we should use profiling to
> determine what to do besides the basic scalar cleanups.
Yup yup.
> 
> 
> Diego.
> 
>