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

[sudi at gcc dot gnu.org]

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

--- Comment #22 from sudi at gcc dot gnu.org ---
Author: sudi
Date: Wed Mar 21 17:14:48 2018
New Revision: 258723

URL: https://gcc.gnu.org/viewcvs?rev=258723=gcc=rev
Log:
[ARM] Fix test pr82989.c for big endian and mthumb

The test pr82989.c which was added in one of previous commits is failing for
mthumb and big-endian configurations. The aim of this test was to check that
NEON instructions are not being used for simple shift operations. The scanning
of lsl and lsr instructions and checking its counts were just too restrictive
for different configurations. So I have now simplified the test to only check
for the absence of NEON instructions.

*** gcc/testsuite/ChangeLog ***

2018-03-21  Sudakshina Das  

PR target/82989
* gcc.target/arm/pr82989.c: Change dg scan-assembly directives.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/arm/pr82989.c

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

[sudi at gcc dot gnu.org]

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

--- Comment #21 from sudi at gcc dot gnu.org ---
Author: sudi
Date: Tue Mar 20 10:54:42 2018
New Revision: 258677

URL: https://gcc.gnu.org/viewcvs?rev=258677=gcc=rev
Log:
[ARM][PR82989] Fix unexpected use of NEON instructions for shifts

This patch fixes PR82989 so that we avoid NEON instructions when
-mneon-for-64bits is not enabled. This is more of a short term fix
for the real deeper problem of making an early decision of choosing
or rejecting NEON instructions. There is now a new ticket PR84467 to
deal with the longer term solution.
(Please refer to the discussion in the bug report for more details).

Sudi

*** gcc/ChangeLog ***

2018-03-20  Sudakshina Das  

PR target/82989
* config/arm/neon.md (ashldi3_neon): Update ?s for constraints
to favor GPR over NEON registers.
(di3_neon): Likewise.

*** gcc/testsuite/ChangeLog ***

2018-03-20  Sudakshina Das  

PR target/82989
* gcc.target/arm/pr82989.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/arm/pr82989.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/neon.md
trunk/gcc/testsuite/ChangeLog

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

[sudi at gcc dot gnu.org]

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

--- Comment #20 from sudi at gcc dot gnu.org ---
Proposed patch
https://gcc.gnu.org/ml/gcc-patches/2018-03/msg00644.html

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

[wilco at gcc dot gnu.org]

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

--- Comment #19 from Wilco  ---
(In reply to sudi from comment #17)
> 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 this PR (which could go
> in sooner). I will also open a new PR to handle this at the expand phase and
> clean up the code aimed at gcc 9.

Looking the history it seems the bad ?'s have been there a long time, since at
least 2010. Initially the patterns used "w, ?r", thus forcing use of Neon in
most cases. This was quickly discovered to be a bad idea and changed into "w,
?r, ?w" with the first w only enabled for non-cortex-a8 cores. Later "onlya8"
was renamed to "avoid_neon_for_64bits" which remains the default today
(eventhough that name doesn't actually mean what it says...).

The anddi3_insn/iordi3_insn/xordi3_inst patterns were fixed by
8ee7dc6fa1a663c9eea8043f84951c1e073468ff when they were merged back into
arm.md, so those use "w, r, ?w".