Hi Tamar,

On 05/02/19 10:13, Tamar Christina wrote:
Hi All,

We currently return cost 2 for NEON REG to REG moves, which would be incorrect
for 64 bit moves.  We currently don't have a pattern for this in the neon_move
alternatives because this is a bit of a special case.  We would almost never
want it to use this r -> r pattern unless it really has no choice.

As such we add a new neon r -> r move pattern but also hide it from being used
to determine register preferences and also disparage it during LRA.

Bootstrapped Regtested on arm-none-gnueabihf and no issues.

Ok for trunk?

Thanks,
Tamar

gcc/ChangeLog:

2019-02-05  Tamar Christina  <tamar.christ...@arm.com>

        PR/target 88850
        * config/arm/neon.md (*neon_mov<mode>): Add r -> r case.

gcc/testsuite/ChangeLog:

2019-02-05  Tamar Christina  <tamar.christ...@arm.com>

        PR/target 88850
        * gcc.target/arm/pr88850.c: New test.

--

diff --git a/gcc/config/arm/neon.md b/gcc/config/arm/neon.md
index 
f9d7ba35b137fed383f84eecbe81dd942943d216..21ff5adbd40c362aa977171bd1726b88b383a265
 100644
--- a/gcc/config/arm/neon.md
+++ b/gcc/config/arm/neon.md
@@ -25,9 +25,9 @@
(define_insn "*neon_mov<mode>"
   [(set (match_operand:VDX 0 "nonimmediate_operand"
-         "=w,Un,w, w,  ?r,?w,?r, ?Us")
+         "=w,Un,w, w,  ?r,?w,?r, ?Us,*r")
        (match_operand:VDX 1 "general_operand"
-         " w,w, Dn,Uni, w, r, Usi,r"))]
+         " w,w, Dn,Uni, w, r, Usi,r,*r"))]
   "TARGET_NEON
    && (register_operand (operands[0], <MODE>mode)
        || register_operand (operands[1], <MODE>mode))"
@@ -62,11 +62,11 @@
 }
  [(set_attr "type" "neon_move<q>,neon_store1_1reg,neon_move<q>,\
                     neon_load1_1reg, neon_to_gp<q>,neon_from_gp<q>,\
-                    neon_load1_2reg, neon_store1_2reg")
-  (set_attr "length" "4,4,4,4,4,4,8,8")
-  (set_attr "arm_pool_range"     "*,*,*,1020,*,*,1020,*")
-  (set_attr "thumb2_pool_range"     "*,*,*,1018,*,*,1018,*")
-  (set_attr "neg_pool_range" "*,*,*,1004,*,*,1004,*")])
+                    neon_load1_2reg, neon_store1_2reg, multiple")
+  (set_attr "length" "4,4,4,4,4,4,8,8,8")
+  (set_attr "arm_pool_range"     "*,*,*,1020,*,*,1020,*,*")
+  (set_attr "thumb2_pool_range"     "*,*,*,1018,*,*,1018,*,*")
+  (set_attr "neg_pool_range" "*,*,*,1004,*,*,1004,*,*")])
So you add a new alternative but don't modify any of the output logic, which 
means it will use
output_move_double. Can that handle an "r,r" alternative?
Or do you expect a split to always happen here? If so, the output should be '#'

Thanks,
Kyrill

Reply via email to