[PATCH GCC8][25/33]New loop constraint flags

[PATCH GCC8][25/33]New loop constraint flags

[Bin Cheng]

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

Hi,
This patch adds new loop constraint flags marking prologue, epilogue and versioned loops generated
by vectorizer, unroller and versioning.  These flags will be used in IVOPTs in order to differentiate
possible hot innermost loop from others.  I also plan to use them to avoid unnecessary cunroll on
such loops.
Is it OK?

Thanks,
bin
2017-04-11  Bin Cheng  <bin.cheng@arm.com>

	* cfgloop.h (LOOP_C_PROLOG, LOOP_C_EPILOG, LOOP_C_VERSION): New.
	* tree-ssa-loop-manip.c (tree_transform_and_unroll_loop): Set
	LOOP_C_EPILOG for unrolled epilogue loop.
	(vect_do_peeling): Set LOOP_C_PROLOG and LOOP_C_EPILOG for peeled
	loops.
	(vect_loop_versioning): Set LOOP_C_VERSION for versioned loop.

[-- Attachment #2: 0025-new-loop-constraint-flags-20170310.txt --]
[-- Type: text/plain, Size: 2739 bytes --]

From 432006f72b95826eadb4c972a55b1aeb89c9998b Mon Sep 17 00:00:00 2001
From: Bin Cheng <binche01@e108451-lin.cambridge.arm.com>
Date: Thu, 30 Mar 2017 10:56:19 +0100
Subject: [PATCH 25/33] new-loop-constraint-flags-20170310.txt

---
 gcc/cfgloop.h              | 6 ++++++
 gcc/tree-ssa-loop-manip.c  | 1 +
 gcc/tree-vect-loop-manip.c | 3 +++
 3 files changed, 10 insertions(+)

diff --git a/gcc/cfgloop.h b/gcc/cfgloop.h
index a8bec1d..90be4cc 100644
--- a/gcc/cfgloop.h
+++ b/gcc/cfgloop.h
@@ -248,6 +248,12 @@ struct GTY ((chain_next ("%h.next"))) loop {
 #define LOOP_C_INFINITE		(1 << 0)
 /* Set if the loop is known to be finite without any assumptions.  */
 #define LOOP_C_FINITE		(1 << 1)
+/* Set if the loop is peeled prologue loop.  */
+#define LOOP_C_PROLOG		(1 << 2)
+/* Set if the loop is peeled epilogue loop.  */
+#define LOOP_C_EPILOG		(1 << 3)
+/* Set if the loop is versioned loop.  */
+#define LOOP_C_VERSION		(1 << 4)
 
 /* Set C to the LOOP constraint.  */
 static inline void
diff --git a/gcc/tree-ssa-loop-manip.c b/gcc/tree-ssa-loop-manip.c
index 22c832a..0559904 100644
--- a/gcc/tree-ssa-loop-manip.c
+++ b/gcc/tree-ssa-loop-manip.c
@@ -1233,6 +1233,7 @@ tree_transform_and_unroll_loop (struct loop *loop, unsigned factor,
 			   scale_unrolled, scale_rest, true);
   gcc_assert (new_loop != NULL);
   update_ssa (TODO_update_ssa);
+  loop_constraint_set (new_loop, LOOP_C_EPILOG);
 
   /* Prepare the cfg and update the phi nodes.  Move the loop exit to the
      loop latch (and make its condition dummy, for the moment).  */
diff --git a/gcc/tree-vect-loop-manip.c b/gcc/tree-vect-loop-manip.c
index f48336b..faeaa6d 100644
--- a/gcc/tree-vect-loop-manip.c
+++ b/gcc/tree-vect-loop-manip.c
@@ -1735,6 +1735,7 @@ vect_do_peeling (loop_vec_info loop_vinfo, tree niters, tree nitersm1,
 	  gcc_unreachable ();
 	}
       slpeel_update_phi_nodes_for_loops (loop_vinfo, prolog, loop, true);
+      loop_constraint_set (prolog, LOOP_C_PROLOG);
       first_loop = prolog;
       reset_original_copy_tables ();
 
@@ -1799,6 +1800,7 @@ vect_do_peeling (loop_vec_info loop_vinfo, tree niters, tree nitersm1,
 	  gcc_unreachable ();
 	}
       slpeel_update_phi_nodes_for_loops (loop_vinfo, loop, epilog, false);
+      loop_constraint_set (epilog, LOOP_C_EPILOG);
 
       /* Scalar version loop may be preferred.  In this case, add guard
 	 and skip to epilog.  Note this only happens when the number of
@@ -2400,6 +2402,7 @@ vect_loop_versioning (loop_vec_info loop_vinfo,
 			  prob, REG_BR_PROB_BASE - prob,
 			  prob, REG_BR_PROB_BASE - prob, true);
 
+  loop_constraint_set (nloop, LOOP_C_VERSION);
   if (version_niter)
     {
       /* The versioned loop could be infinite, we need to clear existing
-- 
1.9.1

Re: [PATCH GCC8][25/33]New loop constraint flags

[Richard Biener]

On Tue, Apr 18, 2017 at 12:51 PM, Bin Cheng <Bin.Cheng@arm.com> wrote:
> Hi,
> This patch adds new loop constraint flags marking prologue, epilogue and versioned loops generated
> by vectorizer, unroller and versioning.  These flags will be used in IVOPTs in order to differentiate
> possible hot innermost loop from others.  I also plan to use them to avoid unnecessary cunroll on
> such loops.
> Is it OK?

Hmm, it doesn't really match "constraints".

I'd rather somehow track the "original" loop it was versioned / copied
from plus either a
"kind" (epilogue, prologue, version) or determine this from dominance
relationship between
the copy and the original loop.

Thus,

struct loop {
 ...
 /* If not zero the loop number this loop was copied from.  */
 unsigned clone_of;

would that help?  With knowing loop relation we can also more
aggressively version
and eventually later collapse the two versions again if we can still
identify them and
they are still reasonably similar.

Richard.

>
> Thanks,
> bin
> 2017-04-11  Bin Cheng  <bin.cheng@arm.com>
>
>         * cfgloop.h (LOOP_C_PROLOG, LOOP_C_EPILOG, LOOP_C_VERSION): New.
>         * tree-ssa-loop-manip.c (tree_transform_and_unroll_loop): Set
>         LOOP_C_EPILOG for unrolled epilogue loop.
>         (vect_do_peeling): Set LOOP_C_PROLOG and LOOP_C_EPILOG for peeled
>         loops.
>         (vect_loop_versioning): Set LOOP_C_VERSION for versioned loop.

Re: [PATCH GCC8][25/33]New loop constraint flags

[Bin.Cheng]

On Wed, Apr 26, 2017 at 2:27 PM, Richard Biener
<richard.guenther@gmail.com> wrote:
> On Tue, Apr 18, 2017 at 12:51 PM, Bin Cheng <Bin.Cheng@arm.com> wrote:
>> Hi,
>> This patch adds new loop constraint flags marking prologue, epilogue and versioned loops generated
>> by vectorizer, unroller and versioning.  These flags will be used in IVOPTs in order to differentiate
>> possible hot innermost loop from others.  I also plan to use them to avoid unnecessary cunroll on
>> such loops.
>> Is it OK?
>
> Hmm, it doesn't really match "constraints".
>
> I'd rather somehow track the "original" loop it was versioned / copied
> from plus either a
> "kind" (epilogue, prologue, version) or determine this from dominance
> relationship between
> the copy and the original loop.
Or we generalize "constraints flags", saying to introduce general
bit-wise flags for loop structure.  Among these flags, one kind is
constraint flags, the rest are general flags.  We could also change
boolean fields into such flags?
I do have following patches relying on this to avoid complete unroll
for prologue/epilogue loops.
>
> Thus,
>
> struct loop {
>  ...
>  /* If not zero the loop number this loop was copied from.  */
>  unsigned clone_of;
In this case, we need to track between different loops, which looks
like a burden.  For example, we need to make sure loop number won't be
reused.  Even more complicated, considering in extreme case that the
original loop could be removed.

>
> would that help?  With knowing loop relation we can also more
> aggressively version
> and eventually later collapse the two versions again if we can still
> identify them and
> they are still reasonably similar.
>
> Richard.
>
>>
>> Thanks,
>> bin
>> 2017-04-11  Bin Cheng  <bin.cheng@arm.com>
>>
>>         * cfgloop.h (LOOP_C_PROLOG, LOOP_C_EPILOG, LOOP_C_VERSION): New.
>>         * tree-ssa-loop-manip.c (tree_transform_and_unroll_loop): Set
>>         LOOP_C_EPILOG for unrolled epilogue loop.
>>         (vect_do_peeling): Set LOOP_C_PROLOG and LOOP_C_EPILOG for peeled
>>         loops.
>>         (vect_loop_versioning): Set LOOP_C_VERSION for versioned loop.

Re: [PATCH GCC8][25/33]New loop constraint flags

[Bin.Cheng]

On Wed, Apr 26, 2017 at 3:01 PM, Bin.Cheng <amker.cheng@gmail.com> wrote:
> On Wed, Apr 26, 2017 at 2:27 PM, Richard Biener
> <richard.guenther@gmail.com> wrote:
>> On Tue, Apr 18, 2017 at 12:51 PM, Bin Cheng <Bin.Cheng@arm.com> wrote:
>>> Hi,
>>> This patch adds new loop constraint flags marking prologue, epilogue and versioned loops generated
>>> by vectorizer, unroller and versioning.  These flags will be used in IVOPTs in order to differentiate
>>> possible hot innermost loop from others.  I also plan to use them to avoid unnecessary cunroll on
>>> such loops.
>>> Is it OK?
>>
>> Hmm, it doesn't really match "constraints".
>>
>> I'd rather somehow track the "original" loop it was versioned / copied
>> from plus either a
>> "kind" (epilogue, prologue, version) or determine this from dominance
>> relationship between
>> the copy and the original loop.
> Or we generalize "constraints flags", saying to introduce general
> bit-wise flags for loop structure.  Among these flags, one kind is
> constraint flags, the rest are general flags.  We could also change
> boolean fields into such flags?
> I do have following patches relying on this to avoid complete unroll
> for prologue/epilogue loops.
>>
>> Thus,
>>
>> struct loop {
>>  ...
>>  /* If not zero the loop number this loop was copied from.  */
>>  unsigned clone_of;
> In this case, we need to track between different loops, which looks
> like a burden.  For example, we need to make sure loop number won't be
> reused.  Even more complicated, considering in extreme case that the
> original loop could be removed.
>
I will drop this one from this patch series.

Thanks,
bin
>>
>> would that help?  With knowing loop relation we can also more
>> aggressively version
>> and eventually later collapse the two versions again if we can still
>> identify them and
>> they are still reasonably similar.
>>
>> Richard.
>>
>>>
>>> Thanks,
>>> bin
>>> 2017-04-11  Bin Cheng  <bin.cheng@arm.com>
>>>
>>>         * cfgloop.h (LOOP_C_PROLOG, LOOP_C_EPILOG, LOOP_C_VERSION): New.
>>>         * tree-ssa-loop-manip.c (tree_transform_and_unroll_loop): Set
>>>         LOOP_C_EPILOG for unrolled epilogue loop.
>>>         (vect_do_peeling): Set LOOP_C_PROLOG and LOOP_C_EPILOG for peeled
>>>         loops.
>>>         (vect_loop_versioning): Set LOOP_C_VERSION for versioned loop.