Re: Combine four insns

["H.J. Lu" <hjl.tools@gmail.com>]

On Thu, Aug 19, 2010 at 10:37 AM, Bernd Schmidt <bernds@codesourcery.com> 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:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45350


-- 
H.J.