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
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
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 swi
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,
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 cy
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 instructions/it
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 per
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82989
Jakub Jelinek changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--- Comment
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 Wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82989
sudi at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
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 arm-linux-gnueabihf
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 h
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
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).
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82989
Jakub Jelinek changed:
What|Removed |Added
CC||ktkachov at gcc dot gnu.org,
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82989
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |7.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82989
--- Comment #2 from Ramana Radhakrishnan ---
Works as expected in GCC 6.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82989
Ramana Radhakrishnan changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
20 matches
Mail list logo