[PATCH][PR tree-optimization/69196] Improve accounting in backwards (FSM) threader
Another step along the path to fixing 69196. As I was investigating the
regression, one of the things that became quite clear was that we'd
greatly increased the number of PHIs and many of the PHI arguments were
constants (which in turn never coalesce and thus generate a constant
initialization).
I think this addresses the accounting issues relevant to 69196 in the
backwards (FSM) threader. I don't expect this patch in and of itself to
have any significant impact on the testcase -- it's just preparatory
work for the clamp.
Bootstrapped and regression tested on x86_64-linux-gnu. Installed on
the trunk.
Jeff
commit 5810fc48902c737b3e0ea24bd2a709edbde41ff2
Author: Jeff Law
Date: Tue Mar 1 14:41:35 2016 -0700
PR tree-optimization/69196
* tree-ssa-threadbackward.c (fsm_find_control_statement_thread_paths):
Do count some PHIs in the thread path against the insn count. Decrease
final statement count by one as the control statement in the last
block will get removed. Remove special cased code for handling PHIs
in the last block.
PR tree-optimization/69196
* gcc.dg/tree-ssa/vrp46.c: Twiddle threading params to keep it from
duplicating code and spoiling the expected output.
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index b758d42..c1f2557 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,11 @@
+2016-03-01 Jeff Law
+
+ PR tree-optimization/69196
+ * tree-ssa-threadbackward.c (fsm_find_control_statement_thread_paths):
+ Do count some PHIs in the thread path against the insn count. Decrease
+ final statement count by one as the control statement in the last
+ block will get removed. Remove special cased code for handling PHIs
in the last block.
+
2016-03-01 Uros Bizjak
PR target/70027
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 000ece8..ef8a987 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,9 @@
+2016-03-01 Jeff Law
+
+ PR tree-optimization/69196
+ * gcc.dg/tree-ssa/vrp46.c: Twiddle threading params to keep it from
+ duplicating code and spoiling the expected output.
+
2016-03-01 Michael Meissner
PR target/70033
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/vrp46.c
b/gcc/testsuite/gcc.dg/tree-ssa/vrp46.c
index 8923eb4..d3c9ed1 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/vrp46.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/vrp46.c
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-options "-O2 -fdump-tree-vrp1" } */
+/* { dg-options "-O2 -fdump-tree-vrp1 --param fsm-scale-path-blocks=1" } */
int func_81 (int);
int func_98 (int);
diff --git a/gcc/tree-ssa-threadbackward.c b/gcc/tree-ssa-threadbackward.c
index 55dbcad..3028504 100644
--- a/gcc/tree-ssa-threadbackward.c
+++ b/gcc/tree-ssa-threadbackward.c
@@ -286,6 +286,37 @@ fsm_find_control_statement_thread_paths (tree name,
break;
}
+ /* PHIs in the path will create degenerate PHIS in the
+copied path which will then get propagated away, so
+looking at just the duplicate path the PHIs would
+seem unimportant.
+
+But those PHIs, because they're assignments to objects
+typically with lives that exist outside the thread path,
+will tend to generate PHIs (or at least new PHI arguments)
+at points where we leave the thread path and rejoin
+the original blocks. So we do want to account for them.
+
+We ignore virtual PHIs. We also ignore cases where BB
+has a single incoming edge. That's the most common
+degenerate PHI we'll see here. Finally we ignore PHIs
+that are associated with the value we're tracking as
+that object likely dies. */
+ if (EDGE_COUNT (bb->succs) > 1 && EDGE_COUNT (bb->preds) > 1)
+ {
+ for (gphi_iterator gsip = gsi_start_phis (bb);
+ !gsi_end_p (gsip);
+ gsi_next (&gsip))
+ {
+ gphi *phi = gsip.phi ();
+ tree dst = gimple_phi_result (phi);
+
+ if (SSA_NAME_VAR (dst) != SSA_NAME_VAR (name)
+ && !virtual_operand_p (dst))
+ ++n_insns;
+ }
+ }
+
for (gsi = gsi_after_labels (bb);
!gsi_end_p (gsi);
gsi_next_nondebug (&gsi))
@@ -324,6 +355,11 @@ fsm_find_control_statement_thread_paths (tree name,
threaded_through_latch = true;
}
+ /* We are going to remove the control statement at the end of the
+
Re: [PATCH][PR tree-optimization/69196] Improve accounting in backwards (FSM) threader
On Tue, Mar 1, 2016 at 10:46 PM, Jeff Law wrote:
>
>
> Another step along the path to fixing 69196. As I was investigating the
> regression, one of the things that became quite clear was that we'd greatly
> increased the number of PHIs and many of the PHI arguments were constants
> (which in turn never coalesce and thus generate a constant initialization).
>
> I think this addresses the accounting issues relevant to 69196 in the
> backwards (FSM) threader. I don't expect this patch in and of itself to
> have any significant impact on the testcase -- it's just preparatory work
> for the clamp.
>
> Bootstrapped and regression tested on x86_64-linux-gnu. Installed on the
> trunk.
>
> Jeff
>
> commit 5810fc48902c737b3e0ea24bd2a709edbde41ff2
> Author: Jeff Law
> Date: Tue Mar 1 14:41:35 2016 -0700
>
> PR tree-optimization/69196
> * tree-ssa-threadbackward.c
> (fsm_find_control_statement_thread_paths):
> Do count some PHIs in the thread path against the insn count.
> Decrease
> final statement count by one as the control statement in the last
> block will get removed. Remove special cased code for handling PHIs
> in the last block.
>
> PR tree-optimization/69196
> * gcc.dg/tree-ssa/vrp46.c: Twiddle threading params to keep it from
> duplicating code and spoiling the expected output.
>
> diff --git a/gcc/ChangeLog b/gcc/ChangeLog
> index b758d42..c1f2557 100644
> --- a/gcc/ChangeLog
> +++ b/gcc/ChangeLog
> @@ -1,3 +1,11 @@
> +2016-03-01 Jeff Law
> +
> + PR tree-optimization/69196
> + * tree-ssa-threadbackward.c
> (fsm_find_control_statement_thread_paths):
> + Do count some PHIs in the thread path against the insn count.
> Decrease
> + final statement count by one as the control statement in the last
> + block will get removed. Remove special cased code for handling PHIs
> in the last block.
> +
> 2016-03-01 Uros Bizjak
>
> PR target/70027
> diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
> index 000ece8..ef8a987 100644
> --- a/gcc/testsuite/ChangeLog
> +++ b/gcc/testsuite/ChangeLog
> @@ -1,3 +1,9 @@
> +2016-03-01 Jeff Law
> +
> + PR tree-optimization/69196
> + * gcc.dg/tree-ssa/vrp46.c: Twiddle threading params to keep it from
> + duplicating code and spoiling the expected output.
> +
> 2016-03-01 Michael Meissner
>
> PR target/70033
> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/vrp46.c
> b/gcc/testsuite/gcc.dg/tree-ssa/vrp46.c
> index 8923eb4..d3c9ed1 100644
> --- a/gcc/testsuite/gcc.dg/tree-ssa/vrp46.c
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/vrp46.c
> @@ -1,5 +1,5 @@
> /* { dg-do compile } */
> -/* { dg-options "-O2 -fdump-tree-vrp1" } */
> +/* { dg-options "-O2 -fdump-tree-vrp1 --param fsm-scale-path-blocks=1" } */
>
> int func_81 (int);
> int func_98 (int);
> diff --git a/gcc/tree-ssa-threadbackward.c b/gcc/tree-ssa-threadbackward.c
> index 55dbcad..3028504 100644
> --- a/gcc/tree-ssa-threadbackward.c
> +++ b/gcc/tree-ssa-threadbackward.c
> @@ -286,6 +286,37 @@ fsm_find_control_statement_thread_paths (tree name,
> break;
> }
>
> + /* PHIs in the path will create degenerate PHIS in the
> +copied path which will then get propagated away, so
> +looking at just the duplicate path the PHIs would
> +seem unimportant.
> +
> +But those PHIs, because they're assignments to objects
> +typically with lives that exist outside the thread
> path,
> +will tend to generate PHIs (or at least new PHI
> arguments)
> +at points where we leave the thread path and rejoin
> +the original blocks. So we do want to account for
> them.
> +
> +We ignore virtual PHIs. We also ignore cases where BB
> +has a single incoming edge. That's the most common
> +degenerate PHI we'll see here. Finally we ignore PHIs
> +that are associated with the value we're tracking as
> +that object likely dies. */
> + if (EDGE_COUNT (bb->succs) > 1 && EDGE_COUNT (bb->preds) >
> 1)
> + {
> + for (gphi_iterator gsip = gsi_start_phis (bb);
> + !gsi_end_p (gsip);
> + gsi_next (&gsip))
> + {
> + gphi *phi = gsip.phi ();
> + tree dst = gimple_phi_result (phi);
> +
> + if (SSA_NAME_VAR (dst) != SSA_NAME_VAR (name)
I think this doesn't quite work, to make it match the comment you'd have to add
a SSA_NAME_VAR (dst) != NULL_TREE check as otherwise all anonymous
SSA names count as "the same value we're tracking". Shouldn't you simply
compare the SSA names themselves but for the operand correspon
Re: [PATCH][PR tree-optimization/69196] Improve accounting in backwards (FSM) threader
On 03/02/2016 03:51 AM, Richard Biener wrote:
On Tue, Mar 1, 2016 at 10:46 PM, Jeff Law wrote:
Another step along the path to fixing 69196. As I was investigating the
regression, one of the things that became quite clear was that we'd greatly
increased the number of PHIs and many of the PHI arguments were constants
(which in turn never coalesce and thus generate a constant initialization).
I think this addresses the accounting issues relevant to 69196 in the
backwards (FSM) threader. I don't expect this patch in and of itself to
have any significant impact on the testcase -- it's just preparatory work
for the clamp.
Bootstrapped and regression tested on x86_64-linux-gnu. Installed on the
trunk.
Jeff
commit 5810fc48902c737b3e0ea24bd2a709edbde41ff2
Author: Jeff Law
Date: Tue Mar 1 14:41:35 2016 -0700
PR tree-optimization/69196
* tree-ssa-threadbackward.c
(fsm_find_control_statement_thread_paths):
Do count some PHIs in the thread path against the insn count.
Decrease
final statement count by one as the control statement in the last
block will get removed. Remove special cased code for handling PHIs
in the last block.
PR tree-optimization/69196
* gcc.dg/tree-ssa/vrp46.c: Twiddle threading params to keep it from
duplicating code and spoiling the expected output.
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index b758d42..c1f2557 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,11 @@
+2016-03-01 Jeff Law
+
+ PR tree-optimization/69196
+ * tree-ssa-threadbackward.c
(fsm_find_control_statement_thread_paths):
+ Do count some PHIs in the thread path against the insn count.
Decrease
+ final statement count by one as the control statement in the last
+ block will get removed. Remove special cased code for handling PHIs
in the last block.
+
2016-03-01 Uros Bizjak
PR target/70027
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 000ece8..ef8a987 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,9 @@
+2016-03-01 Jeff Law
+
+ PR tree-optimization/69196
+ * gcc.dg/tree-ssa/vrp46.c: Twiddle threading params to keep it from
+ duplicating code and spoiling the expected output.
+
2016-03-01 Michael Meissner
PR target/70033
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/vrp46.c
b/gcc/testsuite/gcc.dg/tree-ssa/vrp46.c
index 8923eb4..d3c9ed1 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/vrp46.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/vrp46.c
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-options "-O2 -fdump-tree-vrp1" } */
+/* { dg-options "-O2 -fdump-tree-vrp1 --param fsm-scale-path-blocks=1" } */
int func_81 (int);
int func_98 (int);
diff --git a/gcc/tree-ssa-threadbackward.c b/gcc/tree-ssa-threadbackward.c
index 55dbcad..3028504 100644
--- a/gcc/tree-ssa-threadbackward.c
+++ b/gcc/tree-ssa-threadbackward.c
@@ -286,6 +286,37 @@ fsm_find_control_statement_thread_paths (tree name,
break;
}
+ /* PHIs in the path will create degenerate PHIS in the
+copied path which will then get propagated away, so
+looking at just the duplicate path the PHIs would
+seem unimportant.
+
+But those PHIs, because they're assignments to objects
+typically with lives that exist outside the thread
path,
+will tend to generate PHIs (or at least new PHI
arguments)
+at points where we leave the thread path and rejoin
+the original blocks. So we do want to account for
them.
+
+We ignore virtual PHIs. We also ignore cases where BB
+has a single incoming edge. That's the most common
+degenerate PHI we'll see here. Finally we ignore PHIs
+that are associated with the value we're tracking as
+that object likely dies. */
+ if (EDGE_COUNT (bb->succs) > 1 && EDGE_COUNT (bb->preds) >
1)
+ {
+ for (gphi_iterator gsip = gsi_start_phis (bb);
+ !gsi_end_p (gsip);
+ gsi_next (&gsip))
+ {
+ gphi *phi = gsip.phi ();
+ tree dst = gimple_phi_result (phi);
+
+ if (SSA_NAME_VAR (dst) != SSA_NAME_VAR (name)
I think this doesn't quite work, to make it match the comment you'd have to add
a SSA_NAME_VAR (dst) != NULL_TREE check as otherwise all anonymous
SSA names count as "the same value we're tracking". Shouldn't you simply
compare the SSA names themselves but for the operand corresponding to
the edge we are threading instead of the PHI result?
Without testing, yea, I think SSA_NAME_VAR != NULL_TREE ought to be
added to handle anonymo
Re: [PATCH][PR tree-optimization/69196] Improve accounting in backwards (FSM) threader
On 03/02/2016 11:58 AM, Jeff Law wrote: I think this doesn't quite work, to make it match the comment you'd have to add a SSA_NAME_VAR (dst) != NULL_TREE check as otherwise all anonymous SSA names count as "the same value we're tracking". Shouldn't you simply compare the SSA names themselves but for the operand corresponding to the edge we are threading instead of the PHI result? Without testing, yea, I think SSA_NAME_VAR != NULL_TREE ought to be added to handle anonymous names. So some raw data. 66% of the time both objects have an underlying SSA_NAME_VAR and we can make an accurate guess if they're related or not by looking at the underlying object. 17% of the time the name we're tracking has an SSA_NAME_VAR, but the result of the PHI does not. Assuming the names are not related is probably accurate here too. 3% of the time the name we're tracking is anonymous, but the result of the PHI is not. Again, assuming names are not related is probably accurate. Note the low value here is not unexpected. Leaving the remaining 14% where both names are anonymous. Which is the case we're getting wrong right now. I think the safe thing to do without significant further investment is to consider the names unrelated in this case, which I'm testing now. If we wanted to do better here we could do things like building partitions similar to what we do for coalescing. If the objects end up in the same partition, then consider them related, but that seems like severe overkill here. Jeff
