This is the mail archive of the gcc@gcc.gnu.org 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: IRA copy heuristics


Vladimir Makarov <vmakarov@redhat.com> writes:
> Richard Sandiford wrote:
>
>  > As I mentioned in:
>  >
>  >     http://gcc.gnu.org/ml/gcc/2008-08/msg00476.html
>  >
>  > I'd been working on a MIPS IRA port, but got side-tracked by a wrong-code
>  > regression.
>  >
>  > The regression was caused by incorrect EH liveness information. I tried
>  > to "fix" it by replacing the current note_stores-based forward scan with
>  > a DF-based backwards scan, which gave us the corrected information 
> for free.
>  > However, even after Vlad fixed a pessimisation wrt calls and
>  > DF_REF_MAY_CLOBBER, he saw a significant decrease in SPECFP performance.
>  > It seemed to me (and I think to Vlad) that the differences were caused
>  > by the "inverted" ALLOCNO_NUM ordering.  Before the patch, allocno
>  > indexes typically increased as you went from the beginning of a region
>  > to the end, whereas it was the other way around after the patch.
>  >
>
> I checked SPEC2000 again with your patches and there is no performance
> regression anymore.  Although I checked this with two patches which I
> submitted but did not get an approval yet.

Thanks for testing, and I suppose it's good news that the combined patches
show no regressions.  I'm a bit reluctant to actually apply the first patch
though.  I only wrote it to demonstrate the point I was trying to make.

My understanding -- correct me if I'm wrong -- is that the ALLOCNO_NUM
comparisons are simply tie-breakers to stabilise the sort.  If the
difference between a "index2 - index1" and "index1 - index2" makes a
significant difference, moving from one to the other just feels like
it's papering over a deeper problem.  At least until we know why the
difference matters (at which point we might decide there's no easy,
acceptable fix).

I agree that the lack of an xmm0 tie was the fundamental problem in the
particular example I gave.  Perhaps I didn't put enough emphasis on
that in the original message.  I was banging on about the copy heuristics
because, in the examples I looked at before, it was the the copy heuristics
that were leading us astray for certain ALLOCNO_NUM orderings.  And a
similar problem did occur here, even if it wasn't the primary cause of
the extra copy.

I'll look through my logs for an example that doesn't rely on hard
register ties.  (As I said, it takes quite a while to go through the
detailed differences for a particular test, so I'm not sure how quick
I'll be.)

>  > More fundamentally, C3 ends up having more influence than C2,
>  > even though the copies ostensibly have the same weight.  In other words,
>  > we have the following copy graph:
>  >
>  >     A58 <-> A63 <-> A64 <-> A60
>  >
>  > And the allocation of A63 has more influence over A64 than A60 does,
>  > because of the transitive influence of A58.  But shouldn't this
>  > transitive influence only kick in when A64 is allocated _between_
>  > A58 and A63?  Why should the allocation of A58 matter to A64 if
>  > A63 has already been allocated?
>  >
>
> I'll think about it and try to improve the heuristics. Indirect
> influence of allocno assignment to allocno not connected directly to
> given allocno was added to improve the code generation.

I understand that, and I can see why it's important when the allocation
order is something like A58, A64, A60, A63.  All other things being equal,
it's better to allocate H58 to A64 in that case.  The case I'm worried
about is when the indirect costs via Ax apply _after_ Ax has been
allocated.

> With my point of view, the major problem in this case is in that tying
> of xmm0 with r64 in insn #16 is ignored.  By the way such insns are not
> typical for x86 (I did not find any in SPEC2000). First of all cost
> calculation in regclass (used by the old register allocator) and in
> ira-costs.c (used by IRA) does not take such insns into account.  They
> take into account only move insn involving hard-register of small
> class and pseudo-register.  Ideally the cost for class SSE_FIRST_REG
> should be minimal and allocno for r64 should have SSE_FIRST_REG as the
> best reg class and SSE_REGS as an alternative register class.  It is
> not done.
>
> But the patch
>
> http://gcc.gnu.org/ml/gcc-patches/2008-08/msg02279.html
>
> should solve the problem.  I missed only one thing for this test.
> Instead of `only_regs_p' in ira-conflicts.c::process_regs_for_copy,
> there should be `only_regs_p && insn !=NULL_RTX' to distinguish
> move insn which was already taken into account in ira-costs.c.
> With the patch and the small change, r64 gets xmm0 and the problem
> disappears.  IRA will generate a better code than the
> old RA.

Thanks!

I originally sent the patches as attachments, but they seemed to
get inlined.  I'll try again with gzipped files, just in case.

Richard

Attachment: compare-order.diff.gz
Description: Binary data

Attachment: use-df.diff.gz
Description: Binary data


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