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: IRA preferencing issues

On 17/04/15 09:26 AM, Matthew Fortune wrote:
Wilco Dijkstra <> writes:
While investigating why the IRA preferencing algorithm often chooses
incorrect preferences from the costs, I noticed this thread:

I am seeing the exact same issue on AArch64 - during the final
preference selection ira-costs takes the union of any register classes
that happen to have equal cost. As a result many registers get ALL_REGS
as the preferred register eventhough its cost is much higher than either
GENERAL_REGS or FP_REGS. So we end up with lots of scalar SIMD
instructions and expensive int<->FP moves in integer code when register
pressure is high. When the preference is computed correctly as in the
proposed patch (choosing the first class with lowest cost, ie.
GENERAL_REGS) the resulting code is much more efficient, and there are
no spurious SIMD instructions.

Choosing a preferred class when it doesn't have the lowest cost is
clearly incorrect. So is there a good reason why the proposed patch
should not be applied? I actually wonder why we'd ever need to do a
union - if there are 2 classes with equal cost, you'd use the 2nd as the
alternative class.

The other question I had is whether there is a good way to get improve
the preference in cases like this and avoid classes with equal cost
altogether. The costs are clearly not equal: scalar SIMD instructions
have higher latency and require extra int<->FP moves. It is possible to
mark variants in the MD patterns using '?' to discourage them but that
seems like a hack, just like '*'. Is there a general way to say that
GENERAL_REGS is preferred over FP_REGS for SI/DI mode?
MIPS has the same problem here and we have been looking at ways to address
it purely via costings rather than changing IRA. What we have done so
far is to make the cost of a move from GENERAL_REGS to FP_REGS more
expensive than memory if the move has an integer mode. The goal for MIPS
is to never allocate an FP register to an integer mode unless it was
absolutely necessary owing to an integer to fp conversion where the
integer has to be put in an FP register. Ideally I'd like a guarantee
that FP registers will never be used unless a floating point type is
present in the source but I haven't found a way to do that given the
FP-int conversion issue requiring SImode to be allowed in FP regs.

The patch for MIPS is not submitted yet but has eliminated the final
two uses of FP registers when building the whole Linux kernel with
hard-float enabled. I am however still not confident enough to say
you can build integer only code with hard-float and never touch an FP

Since there are multiple architectures suffering from this I guess we
should look at properly addressing it in generic code.

Wilco, Matt, thanks for sharing your problem cases. It would be nice if you provide a small test case and fill PR in GCC bugzilla, or point me one if it already exists.

Preferred and alternative classes are from old RA which implemented Chow's priority based coloring. This algorithm has a different coloring criteria, generally speaking it can be considered as simultaneous coloring and assigning and permits easy usage of several different priorities reg classes for a pseudo.

IRA uses Chaitin-Briggs coloring originally with Kempe's criteria which is a standard now for industrial optimizing compilers (LLVM is a rare exclusion). It assumes that we have non-intersected reg-classes and each pseudo belongs to one class. New coloring criteria developed on ones proposed by Smith's and Holloway were lately added to IRA. These criteria permit pseudo-register classes form tree (one class can fully include another class). Preferred and alternative classes can not be integrated to Chaitin-Briggs approach (as to undeservedly forgotten Ershow's graph coloring based on merging non-connected nodes of conflict graph).

So we need to use one class in IRA for a pseudo. If we have mem-mem move through a register and floating point or integer register, it would be wrong to choose only one class in case when only one integer or fp register pressure is high.

IRA costs has many drawbacks and I planned to improve it. I believe it should choose insn alternatives first and reg classes after that based on the chosen alternatives.

Wilco, I might be wrong and the patch you mentioned works well (e.g. probability of the above case mem-mem move is small). If you provide data (e.g. on SPEC2000/SPEC2006) for your target how the patch improves the code, we could consider it as some temporary (it might become a permanent) solution until ira-costs.c is rewritten. I myself could measure the patch effect on x86/x86-64 to make a final decision.


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