This is the mail archive of the gcc@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: 3.2 vs 3.1 speed


> Jan Hubicka <jh@suse.cz> writes:
> 
>   > > In message <200206051353.aa01413@gremlin-relay.ics.uci.edu>, Dan Nicolaescu wri
>   > > tes:
>   > >  > 
>   > >  > One of the reasons that 3.2 is slower than 3.1 is that 3.2 just
>   > >  > generates a lot more RTL (also see the huge increase in time spent in
>   > >  > expand).
>   > > Which is rather curious.  What would be even more interesting would be to know
>   > > how much of that RTL is due to the RTL inliner and how much is due to the
>   > > tree inliner.
>   > 
>   > Is the RTL inliner still used?  I don't think so.
> 
> That was my impression too. (as a reminder: these results are for C++ code)
> 
>   > There has been changes to the inlining heuristics, so I guess that will
>   > explain the degradation.  
> 
> It looks like that change has increased the amount of generated code a
> lot. Has it been benchmarked ? 

I believe so.  It showed some perofrmance improvements.
If I remember correctly, there is another incarnation of inliner on AST
branch that has better handling of cascaded inlining, but I didn't
really paid much attention to this area.
> Maybe we should ask the C++ people to run some performance tests to
> see if it was worthwhile... 
> 
>   > Would be possible to know the full -fno-inline comparisons?
> 
> Sure. 
Thanks!
I was mostly curous the the CFG based passes:
>  cfg construction      :   0.43 ( 0%)   cfg construction      :   0.69 ( 1%)
>  cfg cleanup           :   0.56 ( 0%)   cfg cleanup           :   0.52 ( 0%)
>  flow analysis         :   0.33 ( 0%)   flow analysis         :   0.42 ( 0%)
>  if-conversion         :   0.03 ( 0%)   if-conversion         :   0.06 ( 0%)

All these seems to work nicely, so I guess Zdenek's change is in the
right direction.  However we do have some problems in the liveness and
propagation of branch frequencies, still not as bad as I was affraid of.
I will take a look at these soon.

>  life analysis         :   6.27 ( 6%)   life analysis         :   6.09 ( 5%)
>  life info update      :   1.72 ( 2%)   life info update      :   1.62 ( 1%)
>  branch prediction     :   1.50 ( 1%)   				     

This is interesting, what ifcvt2 does not machines not supporting
conditional execution?  I think it can be disabled.  Not big deal tought
>  if-conversion 2       :   0.04 ( 0%)   if-conversion 2       :   0.03 ( 0%)

Thanks,
Honza


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