Hi, While investigating why the IRA preferencing algorithm often chooses incorrect preferences from the costs, I noticed this thread: https://gcc.gnu.org/ml/gcc/2011-05/msg00186.html
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? Wilco
