This is the mail archive of the 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: Combine four insns

On Thu, Aug 19, 2010 at 10:37 AM, Bernd Schmidt <> wrote:
> On 08/19/2010 09:38 AM, Eric Botcazou wrote:
>>> Mark said the plan was sensible, so I think there is no tie.
>> Sorry, this is such a bad decision in my opinion, as it will set a precedent
>> for one-percent-slowdown-for-very-little-benefit patches, that I think an
>> explicit OK is in order.
> We're no longer discussing the 1% slower patch. ?I'll even agree that
> that's a bit excessive, and the approval for it surprised me, but it
> served to get a discussion going. ?Several people provided datapoints
> indicating that time spent in the optimizers at -O2 or higher is
> something that just isn't on the radar as a valid concern based both on
> usage patterns and profiling results which show that most time is spent
> elsewhere.
> As for the patch itself, Michael Matz provided constructive feedback
> which led to a heuristic that eliminated a large number of combine-4
> attempts. ?I conclude that either you didn't read the thread before
> attempting once again to block one of my patches, or the above is more
> than a little disingenuous.
> The following is a slightly updated variant of the previous patch I
> posted. ?I fixed a bug and slightly cleaned up the in_feeds_im logic
> (insn_a_feeds_b isn't valid for insns that aren't consecutive in the
> combination), and I found a way to slightly relax the heuristic in order
> to use Michael's suggestion of allowing combinations if there are two or
> more binary operations with constant operand.
> On i686, the heuristic reduces the combine-4 attempts to slightly over a
> third of the ones tried by the first patch (and presumably disallows
> them in most cases where we'd generate overly large RTL). ?Hence, I
> would have expected this patch to cause slowdowns in the 0.4% range, but
> when I ran a few bootstraps today, I had a few results near 99m5s user
> time with the patch, and the best run without the patch came in at
> 99m10s. ?I don't have enough data to be sure, but some test runs gave me
> the impression that there is one change, using insn_a_feeds_b instead of
> reg_overlap_mentioned_p, which provided some speedup, and may explain
> this result. ?It still seems a little odd.
> Allowing unary ops in the heuristic as well made hardly a difference in
> output, and appeared to cost around 0.3%, so I left it out.
> Bootstrapped and regression tested on i686-linux. ?Committed.

This may have caused:


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