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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79282 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79282 --- Comment #8 from Vladimir Makarov --- Author: vmakarov Date: Tue Feb 14 22:17:19 2017 New Revision: 245459 URL: https://gcc.gnu.org/viewcvs?rev=245459=gcc=rev Log: 2017-02-14 Vladimir Makarov PR target/79282

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79282 --- Comment #7 from Vladimir Makarov --- (In reply to Vladimir Makarov from comment #6) > I think changing pattern > > (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 >

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79282 --- Comment #6 from Vladimir Makarov --- 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

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79282 --- Comment #5 from ktkachov at gcc dot gnu.org --- I suspect just removing the last two alternatives in the pattern is the way to go. They are just copies of the first two but enabled for mneon-for-64bits. If I remove them the test passes for

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79282 --- Comment #4 from Christophe Lyon --- I think the intention is to provide the alternatives with "avoid_neon_for_64bits" as last resort: when Neon is not preferred, but available, we can use it, but prefer to use GPR instead, so try them first.

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79282 --- Comment #3 from Christophe Lyon --- I don't remember well, but it could be related to Richard's comment about cleaning the onlya8 flag: https://gcc.gnu.org/ml/gcc-patches/2012-12/msg01063.html

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79282 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79282 --- Comment #1 from ktkachov at gcc dot gnu.org --- I think this is a problem with the di3_neon pattern in neon.md and in particular the neon_for_64bits/avoid_neon_for_64bits stuff in the arch attribute. I think the last two alternatives that

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79282 Richard Biener changed: What|Removed |Added Priority|P3 |P1 CC|

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79282 ktkachov at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization