This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [tree-ssa-branch] simplify builtins


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


Diego.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]