[Bug target/82989] [7/8 regression] Inexplicable use of NEON for 64-bit math

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82989 --- Comment #18 from sudi at gcc dot gnu.org --- Created bug 84467 to continue discussions about the early expand phase decisions to choose or reject NEON operations

[Bug target/82989] [7/8 regression] Inexplicable use of NEON for 64-bit math

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82989 --- Comment #17 from sudi at gcc dot gnu.org --- Since this looks like a pretty invasive problem, according to my discussions with Wilco and Kyrill, I think I will try to propose a smaller, but temporary fix using the ?s and special casing 32 for

[Bug target/82989] [7/8 regression] Inexplicable use of NEON for 64-bit math

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82989 --- Comment #16 from Wilco --- (In reply to Matthijs van Duin from comment #15) > (In reply to Wilco from comment #14) > > Yes on older cores it can be a bad idea to allow accidental use of Neon > > instructions. The simplest workaround is to

[Bug target/82989] [7/8 regression] Inexplicable use of NEON for 64-bit math

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82989 --- Comment #15 from Matthijs van Duin --- (In reply to Wilco from comment #14) > Yes on older cores it can be a bad idea to allow accidental use of Neon > instructions. The simplest workaround is to switch off Neon, just use > -mfpu=vfp. Sure,

[Bug target/82989] [7/8 regression] Inexplicable use of NEON for 64-bit math

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82989 --- Comment #14 from Wilco --- (In reply to Matthijs van Duin from comment #13) > In case it's of interest, I did a quick benchmark of my testcase executed in > a loop on a cortex-a8: > > Without neon: > 12 instructions/iteration > 14

[Bug target/82989] [7/8 regression] Inexplicable use of NEON for 64-bit math

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82989 --- Comment #13 from Matthijs van Duin --- In case it's of interest, I did a quick benchmark of my testcase executed in a loop on a cortex-a8: Without neon: 12 instructions/iteration 14 cycles/iteration With neon: 14

[Bug target/82989] [7/8 regression ] Inexplicable use of NEON for 64-bit math

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82989 --- Comment #12 from Wilco --- (In reply to Jakub Jelinek from comment #11) > From my completely ARM unaware POV, if NEON is available, it isn't a strict > requirement that NEON must never be used for this, just a matter of > preferences. So

[Bug target/82989] [7/8 regression ] Inexplicable use of NEON for 64-bit math

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82989 Jakub Jelinek changed: What|Removed |Added CC||vmakarov at gcc dot gnu.org --- Comment

[Bug target/82989] [7/8 regression ] Inexplicable use of NEON for 64-bit math

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82989 Wilco changed: What|Removed |Added CC||wilco at gcc dot gnu.org --- Comment #10 from

[Bug target/82989] [7/8 regression ] Inexplicable use of NEON for 64-bit math

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82989 sudi at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED

[Bug target/82989] [7/8 regression ] Inexplicable use of NEON for 64-bit math

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82989 --- Comment #9 from Matthijs van Duin --- I can still reproduce the same test case with: arm-linux-gnueabihf-gcc-8 (Debian 8-20180207-2) 8.0.1 20180207 (experimental) [trunk revision 257435] -mfloat-abi=hard is implicit for

[Bug target/82989] [7/8 regression ] Inexplicable use of NEON for 64-bit math

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82989 --- Comment #8 from Jakub Jelinek --- In both adddi3_neon and lshrdi3_neon the GPR alternatives use exactly the same number of ?s as the NEON ones with avoid_neon_for_64bits, just the neon_for_64bits alternatives don't have any. So I don't see

[Bug target/82989] [7/8 regression ] Inexplicable use of NEON for 64-bit math

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82989 --- Comment #7 from Jakub Jelinek --- Indeed, with -march=armv7-a -mcpu=cortex-a8 -mfpu=neon -O2 pr82989.c -mfloat-abi=hard -mprint-tune-info I can reproduce. prefer_neon_for_64bits seems to be false, and LRA first says: Choosing alt 4 in insn

[Bug target/82989] [7/8 regression ] Inexplicable use of NEON for 64-bit math

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82989 --- Comment #6 from ktkachov at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #5) > Just double-checked this on current trunk and I still can't reproduce this. > Nor with r248000, r245631 nor 244212 I have around (all crosses). > >

[Bug target/82989] [7/8 regression ] Inexplicable use of NEON for 64-bit math

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82989 Jakub Jelinek changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org,

[Bug target/82989] [7/8 regression ] Inexplicable use of NEON for 64-bit math

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82989 Richard Biener changed: What|Removed |Added Target Milestone|7.3 |7.4 --- Comment #4 from Richard Biener

[Bug target/82989] [7/8 regression ] Inexplicable use of NEON for 64-bit math

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82989 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3

[Bug target/82989] [7/8 regression ] Inexplicable use of NEON for 64-bit math

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82989 Richard Biener changed: What|Removed |Added Target Milestone|--- |7.3

[Bug target/82989] [7/8 regression ] Inexplicable use of NEON for 64-bit math

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82989 Ramana Radhakrishnan changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug target/82989] [7/8 regression ] Inexplicable use of NEON for 64-bit math

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82989 --- Comment #2 from Ramana Radhakrishnan --- Works as expected in GCC 6.