public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Bin.Cheng" <amker.cheng@gmail.com>
To: Richard Biener <richard.guenther@gmail.com>
Cc: "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH GCC][11/13]Annotate partition by its parallelism execution type
Date: Fri, 23 Jun 2017 10:24:00 -0000	[thread overview]
Message-ID: <CAHFci2_=xf0dTXQtEk9y2HiEAsSTT+4Sf0HvDN=vGV5MD+=-eA@mail.gmail.com> (raw)
In-Reply-To: <CAFiYyc2WF2NPPrgWRFQd14SzQpjhD+Q58SSnr47b3sh6xQy=Sw@mail.gmail.com>

On Tue, Jun 20, 2017 at 12:34 PM, Richard Biener
<richard.guenther@gmail.com> wrote:
> On Tue, Jun 20, 2017 at 11:18 AM, Bin.Cheng <amker.cheng@gmail.com> wrote:
>> On Fri, Jun 16, 2017 at 11:10 AM, Richard Biener
>> <richard.guenther@gmail.com> wrote:
>>> On Mon, Jun 12, 2017 at 7:03 PM, Bin Cheng <Bin.Cheng@arm.com> wrote:
>>>> Hi,
>>>> This patch checks and records if partition can be executed in parallel by
>>>> looking if there exists data dependence cycles.  The information is needed
>>>> for distribution because the idea is to distribute parallel type partitions
>>>> away from sequential ones.  I believe current distribution doesn't work
>>>> very well because it does blind distribution/fusion.
>>>> Bootstrap and test on x86_64 and AArch64.  Is it OK?
>>>
>>> +  /* In case of no data dependence.  */
>>> +  if (DDR_ARE_DEPENDENT (ddr) == chrec_known)
>>> +    return false;
>>> +  /* Or the data dependence can be resolved by compilation time alias
>>> +     check.  */
>>> +  else if (!alias_sets_conflict_p (get_alias_set (DR_REF (dr1)),
>>> +                                  get_alias_set (DR_REF (dr2))))
>>> +    return false;
>>>
>>> dependence analysis should use TBAA already, in which cases do you need this?
>>> It seems to fall foul of the easy mistake of not honoring GCCs memory model
>>> as well ... see dr_may_alias_p.
>> I see.  Patch updated with this branch removed.
>>
>>>
>>> +  /* Further check if any data dependence prevents us from executing the
>>> +     partition parallelly.  */
>>> +  EXECUTE_IF_SET_IN_BITMAP (partition->reads, 0, i, bi)
>>> +    {
>>> +      dr1 = (*datarefs_vec)[i];
>>> +      EXECUTE_IF_SET_IN_BITMAP (partition->writes, 0, j, bj)
>>> +       {
>>>
>>> what about write-write dependences?
>>>
>>> +  EXECUTE_IF_SET_IN_BITMAP (partition->reads, 0, i, bi)
>>> +    {
>>> +      dr1 = (*datarefs_vec)[i];
>>> +      EXECUTE_IF_SET_IN_BITMAP (partition->writes, i + 1, j, bj)
>>> +       {
>>> +         dr2 = (*datarefs_vec)[j];
>>> +         /* Partition can only be executed sequentially if there is any
>>> +            data dependence cycle.  */
>>>
>>> exact copy of the loop nest follows?!  Maybe you meant to iterate
>>> over writes in the first loop.
>> Yes, this is a copy-paste typo.  Patch is also simplified because
>> read/write are recorded together now.  Is it OK?
>
> Ok.
Sorry I have to update this patch because one of my mistake.  I didn't
update partition type when fusing them.  For some partition fusion,
the update is necessary otherwise we end up with inaccurate type and
inaccurate fusion later.  Is it Ok?

Thanks,
bin
2017-06-20  Bin Cheng  <bin.cheng@arm.com>

    * tree-loop-distribution.c (enum partition_type): New.
    (struct partition): New field type.
    (partition_merge_into): Add parameter.  Update partition type.
    (data_dep_in_cycle_p, update_type_for_merge): New functions.
    (build_rdg_partition_for_vertex): Compute partition type.
    (rdg_build_partitions): Dump partition type.
    (distribute_loop): Update calls to partition_merge_into.

  reply	other threads:[~2017-06-23 10:24 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-12 17:03 Bin Cheng
2017-06-16 10:10 ` Richard Biener
2017-06-20  9:18   ` Bin.Cheng
2017-06-20 11:34     ` Richard Biener
2017-06-23 10:24       ` Bin.Cheng [this message]
2017-06-23 10:25         ` Bin.Cheng
2017-06-23 10:49           ` Richard Biener

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='CAHFci2_=xf0dTXQtEk9y2HiEAsSTT+4Sf0HvDN=vGV5MD+=-eA@mail.gmail.com' \
    --to=amker.cheng@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=richard.guenther@gmail.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).