[tree-ssa-branch] simplify builtins
Sun Jun 30 11:56:00 GMT 2002
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?
> > 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.
> > 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
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.
More information about the Gcc-patches