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.simoesdiasvie...@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.simoesdiasvie...@arm.com>
PR rtl-optimization/98791
* gcc.target/aarch64/sve/pr98791.c: New test.
