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]

IRA preferencing issues


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?


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