This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
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.