public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Tamar Christina <tamar.christina@arm.com>
To: gcc-patches@gcc.gnu.org
Cc: nd@arm.com, Ramana.Radhakrishnan@arm.com,
	Richard.Earnshaw@arm.com,	nickc@redhat.com,
	Kyrylo.Tkachov@arm.com
Subject: [PATCH][GCC][Arm] Fix subreg crash in different way by enabling the FP16 pattern unconditionally.
Date: Mon, 23 Jul 2018 16:56:00 -0000	[thread overview]
Message-ID: <20180723165606.GA7949@arm.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 2443 bytes --]

Hi All,

My previous patch changed arm_can_change_mode_class to allow subregs of
64bit registers on arm big-endian.  However it seems that we can't do this
because a the data in 64 bit VFP registers are stored in little-endian order,
even on big-endian.

Allowing this change had a knock on effect that caused GCC's no-op detection
to think that loading from the first lane on arm big-endian is a no-op.  this
because we can't describe the weird ordering we have on D registers on big-endian.

The original issue comes from the fact that the code does

... foo (... bar)
{
  return bar;
}

The expansion of the return statement causes GCC to try to return the value in
a register.  GCC will try to emit the move then, from MEM to REG (due to the SSA
temporary.).  It checks for a mov optab for this which isn't available and
then tries to do the move in bits using emit_move_multi_word.

emit_move_multi_word will split the move into sub parts, but then needs to get
the sub parts and does this using subregs, but it's told it can't do subregs!

The compiler is now stuck in an infinite loop.

The way this is worked around in the back-end is that we have move patterns in
neon.md that usually just force the register instead of checking with the
back-end. This prevents emit_move_multi_word from being needed.  However the
pattern for V4HF and V8HF were guarded by TARGET_NEON && TARGET_FP16.

I don't believe the TARGET_FP16 guard to be needed, because the pattern doesn't
actually generate code and requires another pattern for that, and a reg to reg move
should always be possible anyway. So allowing the force to register here is safe
and it allows the compiler to generate a correct error instead of ICEing in an
infinite loop.

This patch ensures gcc.target/arm/big-endian-subreg.c is fixed without introducing
any regressions while fixing

gcc.dg/vect/vect-nop-move.c execution test
g++.dg/torture/vshuf-v2si.C   -O3 -g  execution test
g++.dg/torture/vshuf-v4si.C   -O3 -g  execution test
g++.dg/torture/vshuf-v8hi.C   -O3 -g  execution test

Regtested on armeb-none-eabi and no regressions.
Bootstrapped on arm-none-linux-gnueabihf and no issues.


Ok for trunk?

Thanks,
Tamar

gcc/
2018-07-23  Tamar Christina  <tamar.christina@arm.com>

	PR target/84711
	* config/arm/arm.c (arm_can_change_mode_class): Disallow subreg.
	* config/arm/neon.md (movv4hf, movv8hf): Refactored to..
	(mov<mov>): ..this and enable unconditionally.

-- 

[-- Attachment #2: rb9658.patch --]
[-- Type: text/x-diff, Size: 2000 bytes --]

diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index ec3abbcba9fb1ed040bc9cdcf162f5bb4f8df586..8d5897c8f0f93502fb958cba61b7c0b1570d1570 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -31512,8 +31512,8 @@ arm_can_change_mode_class (machine_mode from, machine_mode to,
 {
   if (TARGET_BIG_END
       && !(GET_MODE_SIZE (from) == 16 && GET_MODE_SIZE (to) == 8)
-      && (GET_MODE_UNIT_SIZE (from) > UNITS_PER_WORD
-	  || GET_MODE_UNIT_SIZE (to) > UNITS_PER_WORD)
+      && (GET_MODE_SIZE (from) > UNITS_PER_WORD
+	  || GET_MODE_SIZE (to) > UNITS_PER_WORD)
       && reg_classes_intersect_p (VFP_REGS, rclass))
     return false;
   return true;
diff --git a/gcc/config/arm/neon.md b/gcc/config/arm/neon.md
index 1646b2172970acaaf949ba8b77d43ec72b688d73..57df17fe18dfeaa82e890fd339e2104ad27ee13b 100644
--- a/gcc/config/arm/neon.md
+++ b/gcc/config/arm/neon.md
@@ -137,10 +137,10 @@
     }
 })
 
-(define_expand "movv4hf"
-  [(set (match_operand:V4HF 0 "s_register_operand")
-	(match_operand:V4HF 1 "s_register_operand"))]
-  "TARGET_NEON && TARGET_FP16"
+(define_expand "mov<mode>"
+  [(set (match_operand:VH 0 "s_register_operand")
+	(match_operand:VH 1 "s_register_operand"))]
+  "TARGET_NEON"
 {
   /* We need to use force_reg to avoid TARGET_CAN_CHANGE_MODE_CLASS
      causing an ICE on big-endian because it cannot extract subregs in
@@ -148,22 +148,7 @@
   if (can_create_pseudo_p ())
     {
       if (!REG_P (operands[0]))
-	operands[1] = force_reg (V4HFmode, operands[1]);
-    }
-})
-
-(define_expand "movv8hf"
-  [(set (match_operand:V8HF 0 "")
-	(match_operand:V8HF 1 ""))]
-  "TARGET_NEON && TARGET_FP16"
-{ 
-  /* We need to use force_reg to avoid TARGET_CAN_CHANGE_MODE_CLASS
-     causing an ICE on big-endian because it cannot extract subregs in
-     this case.  */
-  if (can_create_pseudo_p ())
-    {
-      if (!REG_P (operands[0]))
-	operands[1] = force_reg (V8HFmode, operands[1]);
+	operands[1] = force_reg (<MODE>mode, operands[1]);
     }
 })
 


             reply	other threads:[~2018-07-23 16:56 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-23 16:56 Tamar Christina [this message]
2018-07-25  9:55 ` Thomas Preudhomme
2018-07-25 15:28   ` Tamar Christina
2018-07-26  8:29     ` Thomas Preudhomme
2018-07-26 11:03       ` Tamar Christina
2018-07-26 11:33         ` Thomas Preudhomme
2018-07-31  9:46           ` Tamar Christina
2018-08-13  9:31             ` Tamar Christina
2018-08-15 14:25         ` Kyrill Tkachov
2018-09-18 13:12           ` Tamar Christina
2018-09-18 13:24             ` Kyrill Tkachov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180723165606.GA7949@arm.com \
    --to=tamar.christina@arm.com \
    --cc=Kyrylo.Tkachov@arm.com \
    --cc=Ramana.Radhakrishnan@arm.com \
    --cc=Richard.Earnshaw@arm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=nd@arm.com \
    --cc=nickc@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).