On 2021-03-10 5:25 a.m., Andre Vieira (lists) wrote:
On 19/02/2021 15:05, Vladimir Makarov wrote:
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.
Is it OK to backport now? The committed patch applies cleanly and I
regression tested it on gcc-10 branch for aarch64-linux-gnu.
Yes. I did not see any problems with the patch after its submitting.
