Re: [PATCH] Optimize manual byte swap implementations v2

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

Re:

> > How is the compile-time effect on say, cc1files?
>
> Measured using the time command on a x86_64 system:
>
> no bswap		bswap
>
> reload.c:
>
> 0m8.050s		0m8.155s
> 0m8.104s		0m8.141s
> 0m8.094s		0m8.218s
> 0m8.063s		0m8.177s
>
> 8.077s			8.172s		1.118%
>
> combine.c
>
> 0m12.153s		0m12.456s
> 0m12.193s		0m12.335s
> 0m12.194s		0m12.422s
> 0m12.373s		0m12.510s
>
> 12.228s			12.431s		1.66%
>
> gimplify.c
>
> 0m14.907s		0m15.020s
> 0m14.926s		0m15.024s
> 0m14.998s		0m15.147s
> 0m14.916s		0m15.008s
>
> 14.937s			15.05s		0.757%


Sorry, do I understand that the entire compiler is > 1% slower  
because of this one optimization? (Not a rhetorical question, I  
really don't understand what these numbers mean since there's little  
context.)

And when Richard says

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


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.)

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.

Brad