public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* [PATCH, loop-invariant] Fix PR67043: -fcompare-debug failure with -O3
@ 2015-07-31  9:36 Thomas Preud'homme
  2015-07-31 16:07 ` Jeff Law
  0 siblings, 1 reply; 2+ messages in thread
From: Thomas Preud'homme @ 2015-07-31  9:36 UTC (permalink / raw)
  To: Jeff Law, gcc-patches

Hi,

Since commit r223113, loop-invariant pass rely on luids to determine if an invariant can be hoisted out of a loop without introducing temporaries. However, nothing is made to ensure luids are up-to-date. This patch adds a DF_LIVE problem and mark all blocks as dirty before using luids to ensure these will be recomputed.

ChangeLog entries are as follows:


2015-07-31  Thomas Preud'homme  <thomas.preudhomme@arm.com>

        PR tree-optimization/67043
        * loop-invariant.c (find_defs): Force recomputation of all luids.


2015-07-29  Thomas Preud'homme  <thomas.preudhomme@arm.com>

        PR tree-optimization/67043
        * gcc.dg/pr67043.c: New test.

Note: the testcase was heavily reduced from the Linux kernel sources by Markus Trippelsdorf and formatted to follow GNU code style.


diff --git a/gcc/loop-invariant.c b/gcc/loop-invariant.c
index 1fdb84d..fc53e09 100644
--- a/gcc/loop-invariant.c
+++ b/gcc/loop-invariant.c
@@ -676,6 +676,8 @@ find_defs (struct loop *loop)
   df_remove_problem (df_chain);
   df_process_deferred_rescans ();
   df_chain_add_problem (DF_UD_CHAIN);
+  df_live_add_problem ();
+  df_live_set_all_dirty ();
   df_set_flags (DF_RD_PRUNE_DEAD_DEFS);
   df_analyze_loop (loop);
   check_invariant_table_size ();
diff --git a/gcc/testsuite/gcc.dg/pr67043.c b/gcc/testsuite/gcc.dg/pr67043.c
new file mode 100644
index 0000000..36aa686
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr67043.c
@@ -0,0 +1,32 @@
+/* { dg-do compile } */
+/* { dg-options "-O3 -fcompare-debug -w" } */
+
+extern void rt_mutex_owner (void);
+extern void rt_mutex_deadlock_account_lock (int);
+extern void signal_pending (void);
+__typeof__ (int *) a;
+int b;
+
+int
+try_to_take_rt_mutex (int p1) {
+  rt_mutex_owner ();
+  if (b)
+    return 0;
+  rt_mutex_deadlock_account_lock (p1);
+  return 1;
+}
+
+void
+__rt_mutex_slowlock (int p1) {
+  int c;
+  for (;;) {
+    c = ({
+      asm ("" : "=r"(a));
+      a;
+    });
+    if (try_to_take_rt_mutex (c))
+      break;
+    if (__builtin_expect (p1 == 0, 0))
+      signal_pending ();
+  }
+}


Patch was tested by running the testsuite against a bootstrapped native x86_64-linux-gnu GCC and against an arm-none-eabi GCC cross-compiler without any regression.

Is this ok for trunk?

Best regards,

Thomas Preud'homme


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [PATCH, loop-invariant] Fix PR67043: -fcompare-debug failure with -O3
  2015-07-31  9:36 [PATCH, loop-invariant] Fix PR67043: -fcompare-debug failure with -O3 Thomas Preud'homme
@ 2015-07-31 16:07 ` Jeff Law
  0 siblings, 0 replies; 2+ messages in thread
From: Jeff Law @ 2015-07-31 16:07 UTC (permalink / raw)
  To: Thomas Preud'homme, gcc-patches

On 07/31/2015 03:25 AM, Thomas Preud'homme wrote:
> Hi,
>
> Since commit r223113, loop-invariant pass rely on luids to determine if an invariant can be hoisted out of a loop without introducing temporaries. However, nothing is made to ensure luids are up-to-date. This patch adds a DF_LIVE problem and mark all blocks as dirty before using luids to ensure these will be recomputed.
>
> ChangeLog entries are as follows:
>
>
> 2015-07-31  Thomas Preud'homme  <thomas.preudhomme@arm.com>
>
>          PR tree-optimization/67043
>          * loop-invariant.c (find_defs): Force recomputation of all luids.
>
>
> 2015-07-29  Thomas Preud'homme  <thomas.preudhomme@arm.com>
>
>          PR tree-optimization/67043
>          * gcc.dg/pr67043.c: New test.
>
> Note: the testcase was heavily reduced from the Linux kernel sources by Markus Trippelsdorf and formatted to follow GNU code style.
>
>
> diff --git a/gcc/loop-invariant.c b/gcc/loop-invariant.c
> index 1fdb84d..fc53e09 100644
> --- a/gcc/loop-invariant.c
> +++ b/gcc/loop-invariant.c
> @@ -676,6 +676,8 @@ find_defs (struct loop *loop)
>     df_remove_problem (df_chain);
>     df_process_deferred_rescans ();
>     df_chain_add_problem (DF_UD_CHAIN);
> +  df_live_add_problem ();
> +  df_live_set_all_dirty ();
>     df_set_flags (DF_RD_PRUNE_DEAD_DEFS);
>     df_analyze_loop (loop);
>     check_invariant_table_size ();
> diff --git a/gcc/testsuite/gcc.dg/pr67043.c b/gcc/testsuite/gcc.dg/pr67043.c
> new file mode 100644
> index 0000000..36aa686
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/pr67043.c
> @@ -0,0 +1,32 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O3 -fcompare-debug -w" } */
> +
> +extern void rt_mutex_owner (void);
> +extern void rt_mutex_deadlock_account_lock (int);
> +extern void signal_pending (void);
> +__typeof__ (int *) a;
> +int b;
> +
> +int
> +try_to_take_rt_mutex (int p1) {
> +  rt_mutex_owner ();
> +  if (b)
> +    return 0;
> +  rt_mutex_deadlock_account_lock (p1);
> +  return 1;
> +}
> +
> +void
> +__rt_mutex_slowlock (int p1) {
> +  int c;
> +  for (;;) {
> +    c = ({
> +      asm ("" : "=r"(a));
> +      a;
> +    });
> +    if (try_to_take_rt_mutex (c))
> +      break;
> +    if (__builtin_expect (p1 == 0, 0))
> +      signal_pending ();
> +  }
> +}
>
>
> Patch was tested by running the testsuite against a bootstrapped native x86_64-linux-gnu GCC and against an arm-none-eabi GCC cross-compiler without any regression.
>
> Is this ok for trunk?
So if we're relying on LUIDs, don't they get out-of-date each time we 
move an invariant?   Or is there some call back into the DF routines 
after we move an invariant to fix the LUIDs?


jeff

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2015-07-31 15:51 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-07-31  9:36 [PATCH, loop-invariant] Fix PR67043: -fcompare-debug failure with -O3 Thomas Preud'homme
2015-07-31 16:07 ` Jeff Law

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).