https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100328
--- Comment #5 from Kewen Lin <linkw at gcc dot gnu.org> --- Created attachment 51065 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51065&action=edit ira: Consider matching constraint heavily with some parameter v3 The mentioned only one aarch64-linux-gnu "PASS->FAIL" regression failure exposes one issue: how to set up the costs when either of matching constraint two sides is hardware register (hw reg for short later) meanwhile there are several operands can have the matching constraint. Without this patch, the constraint copy is simply taken as a real move insn, so when there is one hw reg, it set the preference and conflict cost as big value, it's good since we used to create constraint copy when there is only one operand respecting matching constraint. With this patch, we allow there are several input operands respecting the same matching constraint (but in different alternatives), so even there is one hw reg, we can't set the preference/conflict cost with high value. CASE 1: hw_reg0 = reg1, reg2, reg3 ... (op1/2/3 has the matching constraint on op0) We can make reg1/reg2/reg3 be preferred to be assigned by hw_reg0 over the other hw_regs. But reg1/reg2/reg3 conflicts with any of the others, we can't make reg1's conflict objects be disparaged on hw_reg0 since it can affect hw_reg0 to be assigned onto reg2/reg3 and also their allocno copies. So make it simply as shuffle copy. CASE 2: reg0 = hw_reg1, reg2, reg3 ... (op1/2/3 has the matching constraint on op0) hw_reg1 is just one option to be assigned to reg0, shouldn't give it much cost otherwise it can disparage reg0's copies with reg2/reg3. Now the patch simple takes it as shuffle copy, so it slightly prefer hw_reg1, but still have the flexibility to go with some hw_reg in reg2/reg3. Note that we can early catch this in function ira_get_dup_out_num, but I think it might be more clear to leave the handling in process_regs_for_copy near the CASE1 handling and easier to tweak it in case we have the need.
