Compiler slowdowns (was Re: [PATCH] Optimize manual byte swap implementations v2)

[Bradley Lucier <lucier at math dot purdue dot edu>]

On Feb 6, 2009, at 5:27 PM, Richard Guenther wrote:

> > \he's not actually citing the e-mail with the timings, so does he  
> > really mean
> > that this is OK?  It appears to me that expensive_optimizations is  
> > turned on
> > at -O2, so will this make the -O2 compiles 1% slower looking for  
> > bswap
> > opportunities?  (Again, a real question, I don't understand the  
> > organization
> > of the passes.c file.)
>
> Yes, I meant that 1% is a reasonable slowdown for -O2.  We can  
> probably
> try to reduce this by not starting the pattern matching from each  
> stmt.

You mean after this patch has been added?  Was

> Timings are ok for expensive_optimizations I guess.  Some more
> comments inline...

an approval for this patch, without this possible reduction?  (Again,  
I can't tell.)

> > In response to a request from Paolo Bonzini I updated data for  
> > PR26854, and
> > on that benchmark cc1 is nearly 36% slower than last September 26,  
> > a bit
> > over 4 months ago.   I don't know what happened over those 4  
> > months, but
> > adding 1% passes for a very specific optimization seems like a  
> > strange
> > trade-off.
>
> Sure, you may think so.

So may others.  Is there any consensus or even group discussion of  
what kind of slowdown is "reasonable"?  Or whether a bswap  
optimization pass is really worth 1% of the entire compile time every  
time the compiler is invoked with -O2?

There is no longer a single pass that takes most of the time in  
PR26854, so it's no longer easy to point to a (metaphorical) nail to  
hammer down.    I certainly can't tell whether passes that show up at  
1% on a timing report are worth that much time, anything below 5%  
doesn't even catch my eye.

And if I ever had anything intelligent to say on this issue, I think  
I've used it all up with my comments above.

Brad