[PATCH][PR98791]: IRA: Make sure allocno copy mode's are ordered

[Vladimir Makarov]

On 2021-02-19 5:53 a.m., Andre Vieira (lists) wrote:
> Hi,
>
> This patch makes sure that allocno copies are not created for 
> unordered modes. The testcases in the PR highlighted a case where an 
> allocno copy was being created for:
> (insn 121 120 123 11 (parallel [
>             (set (reg:VNx2QI 217)
>                 (vec_duplicate:VNx2QI (subreg/s/v:QI (reg:SI 93 [ _2 
> ]) 0)))
>             (clobber (scratch:VNx16BI))
>         ]) 4750 {*vec_duplicatevnx2qi_reg}
>      (expr_list:REG_DEAD (reg:SI 93 [ _2 ])
>         (nil)))
>
> As the compiler detected that the vec_duplicate<mode>_reg pattern 
> allowed the input and output operand to be of the same register class, 
> it tried to create an allocno copy for these two operands, stripping 
> subregs in the process. However, this meant that the copy was between 
> VNx2QI and SI, which have unordered mode precisions.
>
> So at compile time we do not know which of the two modes is smaller 
> which is a requirement when updating allocno copy costs.
>
> Regression tested on aarch64-linux-gnu.
>
> Is this OK for trunk (and after a week backport to gcc-10) ?
>
OK.  Yes, it is wise to wait a bit and see how the patch behaves on the 
trunk before submitting it to gcc-10 branch.  Sometimes such changes can 
have quite unexpected consequences.  But I guess not in this is case.

Thank you for working on the issue.

> gcc/ChangeLog:
> 2021-02-19  Andre Vieira  <andre.simoesdiasvieira@arm.com>
>
>         PR rtl-optimization/98791
>         * ira-conflicts.c (process_regs_for_copy): Don't create 
> allocno copies for unordered modes.
>
> gcc/testsuite/ChangeLog:
> 2021-02-19  Andre Vieira  <andre.simoesdiasvieira@arm.com>
>
>         PR rtl-optimization/98791
>         * gcc.target/aarch64/sve/pr98791.c: New test.
>