public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: michael.hope@linaro.org (Michael Hope)
Cc: gcc-patches@gcc.gnu.org, rearnsha@arm.com,
	ramana.radhakrishnan@linaro.org,        patches@linaro.org
Subject: Re: [patch, arm] Fix PR target/50305 (arm_legitimize_reload_address problem)
Date: Fri, 23 Sep 2011 17:28:00 -0000	[thread overview]
Message-ID: <201109232303.p8NN3Gjt018587@d06av02.portsmouth.uk.ibm.com> (raw)
In-Reply-To: <CANLjY-nad=ndSvOAGURuRkDDrOhfn=fG-mL_BH3YMVedh_UJ5w@mail.gmail.com> from "Michael Hope" at Sep 12, 2011 09:50:45 AM

Michael Hope wrote:
> On Sat, Sep 10, 2011 at 5:04 AM, Ulrich Weigand <uweigand@de.ibm.com> wrote:
> > the problem in PR 50305 turned out to be caused by the ARM back-end
> > LEGITIMIZE_RELOAD_ADDRESS implementation.
> 
> Interesting the fault goes away with -mfpu=neon, perhaps due to the DI
> mode operations getting pushed out into NEON registers.  You might
> want to be explicit about the FPU in dg-options.

Hmm, reload problems tend to be very difficult to reproduce in general,
everything need to line up just so ...   For some reason, I didn't see
the -mfpu=neon effect you describe; I'm seeing the reload failure with
that setting as well.

Nevertheless, I've updated the dg-options as suggested.  I've also added
a dg-skip-if line to prevent problems when using a -march multilib (as
currently discussed in other threads ...).

Richard/Ramana, any thoughts on this?  Is this OK?

Thanks,
Ulrich


ChangeLog:

	gcc/
	PR target/50305
	* config/arm/arm.c (arm_legitimize_reload_address): Recognize
	output of a previous pass through legitimize_reload_address.
	Do not attempt to optimize addresses if the base register is
	equivalent to a constant.

	gcc/testsuite/
	PR target/50305
	* gcc.target/arm/pr50305.c: New test.


Index: gcc/testsuite/gcc.target/arm/pr50305.c
===================================================================
--- gcc/testsuite/gcc.target/arm/pr50305.c	(revision 0)
+++ gcc/testsuite/gcc.target/arm/pr50305.c	(revision 0)
@@ -0,0 +1,60 @@
+/* { dg-do compile } */
+/* { dg-skip-if "incompatible options" { arm*-*-* } { "-march=*" } { "-march=armv7-a" } } */
+/* { dg-options "-O2 -fno-omit-frame-pointer -marm -march=armv7-a -mfpu=vfp3" } */
+
+struct event {
+ unsigned long long id;
+ unsigned int flag;
+};
+
+void dummy(void)
+{
+  /* This is here to ensure that the offset of perf_event_id below
+     relative to the LANCHOR symbol exceeds the allowed displacement.  */
+  static int __warned[300];
+ __warned[0] = 1;
+}
+
+extern void *kmem_cache_alloc_trace (void *cachep);
+extern void *cs_cachep;
+extern int nr_cpu_ids;
+
+struct event *
+event_alloc (int cpu)
+{
+ static unsigned long long __attribute__((aligned(8))) perf_event_id;
+ struct event *event;
+ unsigned long long result;
+ unsigned long tmp;
+
+ if (cpu >= nr_cpu_ids)
+  return 0;
+
+ event = kmem_cache_alloc_trace (cs_cachep);
+
+ __asm__ __volatile__ ("dmb" : : : "memory");
+
+ __asm__ __volatile__("@ atomic64_add_return\n"
+"1:	ldrexd	%0, %H0, [%3]\n"
+"	adds	%0, %0, %4\n"
+"	adc	%H0, %H0, %H4\n"
+"	strexd	%1, %0, %H0, [%3]\n"
+"	teq	%1, #0\n"
+"	bne	1b"
+ : "=&r" (result), "=&r" (tmp), "+Qo" (perf_event_id)
+ : "r" (&perf_event_id), "r" (1LL)
+ : "cc");
+
+ __asm__ __volatile__ ("dmb" : : : "memory");
+
+ event->id = result;
+
+ if (cpu)
+  event->flag = 1;
+
+ for (cpu = 0; cpu < nr_cpu_ids; cpu++)
+   kmem_cache_alloc_trace (cs_cachep);
+
+ return event;
+}
+
Index: gcc/config/arm/arm.c
===================================================================
--- gcc/config/arm/arm.c	(revision 179082)
+++ gcc/config/arm/arm.c	(working copy)
@@ -6550,9 +6550,26 @@
 			       int opnum, int type,
 			       int ind_levels ATTRIBUTE_UNUSED)
 {
+  /* We must recognize output that we have already generated ourselves.  */
   if (GET_CODE (*p) == PLUS
+      && GET_CODE (XEXP (*p, 0)) == PLUS
+      && GET_CODE (XEXP (XEXP (*p, 0), 0)) == REG
+      && GET_CODE (XEXP (XEXP (*p, 0), 1)) == CONST_INT
+      && GET_CODE (XEXP (*p, 1)) == CONST_INT)
+    {
+      push_reload (XEXP (*p, 0), NULL_RTX, &XEXP (*p, 0), NULL,
+		   MODE_BASE_REG_CLASS (mode), GET_MODE (*p),
+		   VOIDmode, 0, 0, opnum, (enum reload_type) type);
+      return true;
+    }
+
+  if (GET_CODE (*p) == PLUS
       && GET_CODE (XEXP (*p, 0)) == REG
       && ARM_REGNO_OK_FOR_BASE_P (REGNO (XEXP (*p, 0)))
+      /* If the base register is equivalent to a constant, let the generic
+	 code handle it.  Otherwise we will run into problems if a future
+	 reload pass decides to rematerialize the constant.  */
+      && !reg_equiv_constant (ORIGINAL_REGNO (XEXP (*p, 0)))
       && GET_CODE (XEXP (*p, 1)) == CONST_INT)
     {
       HOST_WIDE_INT val = INTVAL (XEXP (*p, 1));



-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

  reply	other threads:[~2011-09-23 16:03 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-09 18:14 Ulrich Weigand
2011-09-11 23:26 ` Michael Hope
2011-09-23 17:28   ` Ulrich Weigand [this message]
2011-09-26 10:26 ` Ramana Radhakrishnan
2011-09-26 14:55   ` Ulrich Weigand
2011-09-26 18:02     ` Ramana Radhakrishnan
2011-10-04 15:22       ` Ulrich Weigand
2011-10-06  9:28         ` Ramana Radhakrishnan

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=201109232303.p8NN3Gjt018587@d06av02.portsmouth.uk.ibm.com \
    --to=uweigand@de.ibm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=michael.hope@linaro.org \
    --cc=patches@linaro.org \
    --cc=ramana.radhakrishnan@linaro.org \
    --cc=rearnsha@arm.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).