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

[Richard Guenther <richard dot guenther at gmail dot com>]

On Fri, Feb 6, 2009 at 11:53 PM, Bradley Lucier <lucier@math.purdue.edu> wrote:
>
> 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.)

No, it wasn't an approval.

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

Well, there are several consensuses (heh, does that word even exist?), some
of them are that -O1 should be fast wrt compile-time, -O2 should be good
at optimizing, we don't want passes that are not enabled by default on
any optimization level, -O3 is for things that may even degrade optimization,
-Os should optimize for size.

I don't think enabling byteswap recognition at -O2 is against any of those.

You can disable PRE at -O2 and gain probably more than 1% compile-time
while even seeing runtime speedup on some testcases and some targets.

Etc. - there isn't a right answer.  Generally the consensus in the
past was _not_
that it is ok to cut half of the optimization pipeline and accept that some
testcases are no longer optimized.  Even if I think this would be a good start.

Richard.