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: Collect statistic about how much passes affect function body sizes


> On Tue, 2005-09-27 at 01:36 +0200, Jan Hubicka wrote:
> > Hi,
> > this patch adds flag -ffunction-size-report that collects changes of
> > code size caused by individual tree passes (before and after cleanup
> > TODO is done).  This is report for combine.c:
> > 
> > pass name :   before->   after-> cleanuped  overall
> > ccp       :    37085->   37079->   37079 (-0.02)
> > fre       :    37079->   36815->   36815 (-0.71)
> > forwprop  :    36815->   36794->   36794 (-0.06)
> > vrp       :    36597->   36490->   36480 (-0.92)
> > dce       :    36480->   36417->   36417 (-0.17)
> > dom       :    36417->   36424->   36424 (0.02)
> > phiopt    :    36424->   36422->   36421 (-0.01)
> > alias     :    36421->   36420->   36420 (-0.00)
> > tailr     :    36420->   35987->   35987 (-1.19)
> > ch        :    35987->   36197->   36197 (0.58)
> > dom       :    36197->   36271->   36271 (0.20)
> > copyprop  :    36271->   36271->   36270 (-0.00)
> > dce       :    36270->   36264->   36264 (-0.02)
> > forwprop  :    36264->   36257->   36257 (-0.02)
> > store_ccp :    36257->   36255->   36255 (-0.01)
> > pre       :    36255->   36299->   36299 (0.12)
> > ivcanon   :    36299->   36303->   36303 (0.01)
> > ivopts    :    36303->   36343->   36343 (0.11)
> > dom       :    36343->   36353->   36353 (0.03)
> > copyprop  :    36353->   36353->   36352 (-0.00)
> > cddce     :    36352->   36343->   36343 (-0.02)
> > forwprop  :    36343->   36340->   36340 (-0.01)
> > phiopt    :    36340->   36333->   36333 (-0.02)
> > 
> > I orignally made the patch just to experiment with how inline heuristic
> > interact with optimizations (and what optimizations should be done
> > before inlining), but it seems to be somewhat useful otherwise too (for
> > example to notice that ccp does surprisingly little transformations and
> > lot of stuff that can be considered to be ccp job is caught only by vrp
> > later on).
> Note that many passes do not actually delete the dead code they expose,
> removal of dead code is left for DCE.   To really get accurate
> information you'd have to either run DCE before estimating the size
> after each pass or have the size estimation heuristics somehow
> ignore dead code.
> 
> Though I must admit, I *like* the idea of being able to gather
> these statistics...

I am counting the results of cleanup_cfg separately to make it easier to
see how much was killed by pass itself and how much by the cleanup
afterwards..  We most likely don't want to actually remove the dead code
as that would affect subsequent passes.  Running analysis part of dce in
advance and counting only live statements would be probably doable, but
I am not sure if it is really necesary.  If you suspect pass to mainly
create dead code, you can always look for next scheduled dce pass.  The
last two seems to do pretty little killing however.

Honza
> 
> jeff  
> 


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