[Bug target/79282] [7 Regresion] FAIL: gcc.target/arm/neon-for-64bits-1.c scan-assembler-times vshr 0

vmakarov at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Tue Feb 7 20:50:00 GMT 2017


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79282

--- Comment #6 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
Here is my analysis of the problem.

 The test was successful as LRA actually did not work for the test.
LRA just checked that all insn constraints were satisfied.  If LRA did
any transformation, the test would fail too before the latest changes
in LRA.

The recent changes in LRA force it to do always a live analysis.  If we
have an insn with the following alternative and operands 1 and 2 are
different pseudos assigned to the same hard register by IRA:

&r(1) = 0(2), r(3)

lra-constraints.c decides that the insn does not need any
transformation.  If LRA live analysis is executed, it decides that
pseudos in operands 1 and 2 conflicts because LRA live analysis
(lra-lives.c) ignores the fact that they should be in the same hard
register.

Fixing this bug in LRA would require LRA live analysis to be aware of
the chosen alternative and matched operands.  It is a big change,
implementing this would affect other targets unpredictably.  Probably
it is not wise to do it at this stage.

I think changing pattern

&r(1) = 0(2), r(3)

to

r(1) = 0(2), r(3)

would be a right solution on the target side.  The operand 1 can not
get the same hard register as input operands or other early clobbered
output operands because it should be the same as operand 2 which
already can not be assigned to the same hard reg as other input and
early clobber output operands.

Although I don't know how big the part of .md file will be affected by such
change.


More information about the Gcc-bugs mailing list