This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Optimize manual byte swap implementations v2
- From: Richard Guenther <richard dot guenther at gmail dot com>
- To: Bradley Lucier <lucier at math dot purdue dot edu>
- Cc: Andreas Krebbel <krebbel1 at de dot ibm dot com>, gcc-patches at gcc dot gnu dot org
- Date: Fri, 6 Feb 2009 23:27:36 +0100
- Subject: Re: [PATCH] Optimize manual byte swap implementations v2
- References: <7A20B6C5-6195-44F1-9FF3-8F95C9467F34@math.purdue.edu>
On Fri, Feb 6, 2009 at 11:00 PM, Bradley Lucier <lucier@math.purdue.edu> wrote:
> 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.)
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.
> 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. But in fact GCC has very many "special"
passes like this.
That may be one reason why it is slow, but otoh most of them deal with things
that do not fit in general optimization techniques.
Richard.