public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Bin.Cheng" <amker.cheng@gmail.com>
To: Richard Biener <richard.guenther@gmail.com>
Cc: Steve Ellcey <sellcey@cavium.com>, "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>
Subject: Re: Duplicating loops and virtual phis
Date: Wed, 17 May 2017 09:41:00 -0000	[thread overview]
Message-ID: <CAHFci28LE5ieBGPsP3Cg8W4UbNy0aBC9G70_Dp9sxSVbN455fg@mail.gmail.com> (raw)
In-Reply-To: <F8A43208-D472-42FE-BBEE-702475EE79ED@gmail.com>

On Mon, May 15, 2017 at 7:32 PM, Richard Biener
<richard.guenther@gmail.com> wrote:
> On May 15, 2017 6:56:53 PM GMT+02:00, Steve Ellcey <sellcey@cavium.com> wrote:
>>On Sat, 2017-05-13 at 08:18 +0200, Richard Biener wrote:
>>> On May 12, 2017 10:42:34 PM GMT+02:00, Steve Ellcey <sellcey@cavium.c
>>> om> wrote:
>>> >
>>> > (Short version of this email, is there a way to recalculate/rebuild
>>> > virtual
>>> > phi nodes after modifying the CFG.)
>>> >
>>> > I have a question about duplicating loops and virtual phi nodes.
>>> > I am trying to implement the following optimization as a pass:
>>> >
>>> > Transform:
>>> >
>>> >   for (i = 0; i < n; i++) {
>>> >    A[i] = A[i] + B[i];
>>> >    C[i] = C[i-1] + D[i];
>>> >   }
>>> >
>>> > Into:
>>> >
>>> >   if (noalias between A&B, A&C, A&D)
>>> >    for (i = 0; i < 100; i++)
>>> >            A[i] = A[i] + B[i];
>>> >    for (i = 0; i < 100; i++)
>>> >            C[i] = C[i-1] + D[i];
>>> >   else
>>> >    for (i = 0; i < 100; i++) {
>>> >            A[i] = A[i] + B[i];
>>> >            C[i] = C[i-1] + D[i];
>>> >    }
>>> >
>>> > Right now the vectorizer sees that 'C[i] = C[i-1] + D[i];' cannot
>>be
>>> > vectorized so it gives up and does not vectorize the loop.  If we
>>split
>>> > up the loop into two loops then the vector add with A[i] could be
>>> > vectorized
>>> > even if the one with C[i] could not.
>>> Loop distribution does this transform but it doesn't know about
>>> versioning for unknown dependences.
>>>
>>
>>Yes, I looked at loop distribution.  But it only works with global
>>arrays and not with pointer arguments where it doesn't know the size of
>>the array being pointed at.  I would like to be able to have it work
>>with pointer arguments.  If I call a function with 2 or
>>more integer pointers, and I have a loop that accesses them with
>>offsets between 0 and N where N is loop invariant then I should have
>>enough information (at runtime) to determine if there are overlapping
>>memory accesses through the pointers and determine whether or not I can
>>distribute the loop.
>
> Not sure where you got that from. Loop distribution works with our data reference / dependence analysis.  The cost model might be more restricted but that can be fixed.
>
>>The loop splitting code seemed like a better template since it already
>>knows how to split a loop based on a runtime determined condition. That
>>part seems to be working for me, it is when I try to
>>distribute/duplicate one of those loops (under the unaliased condition)
>>that I am running into the problem with virtual PHIs.
>
> There's mark_virtual*for_renaming (sp?).
>
> But as said you are performing loop distribution so please enhance the existing pass rather than writing a new one.
I happen to be working on loop distribution now (If guess correctly,
to get hmmer fixed).  So far my idea is to fuse the finest distributed
loop in two passes, in the first pass, we merge all SCCs due to "true"
data dependence; in the second one we identify all SCCs and breaks
them on dependent edges due to possible alias.  Breaking SCCs with
minimal edge set can be modeled as Feedback arc set problem which is
NP-hard. Fortunately the problem is small in our case and there are
approximation algorithms.  OTOH, we should also improve loop
distribution/fusion to maximize parallelism / minimize
synchronization, as well as maximize data locality, but I think this
is not needed to get hmmer vectorized.

Thanks,
bin
>
> Richard.
>
>>Steve Ellcey
>>sellcey@cavium.com
>

  reply	other threads:[~2017-05-17  9:41 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-12 20:42 Steve Ellcey
2017-05-13  6:18 ` Richard Biener
2017-05-15 16:56   ` Steve Ellcey
2017-05-15 18:32     ` Richard Biener
2017-05-17  9:41       ` Bin.Cheng [this message]
2017-05-17 15:58         ` Steve Ellcey
2017-05-22  0:42         ` Kugan Vivekanandarajah
2017-05-22  8:31           ` Bin.Cheng

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=CAHFci28LE5ieBGPsP3Cg8W4UbNy0aBC9G70_Dp9sxSVbN455fg@mail.gmail.com \
    --to=amker.cheng@gmail.com \
    --cc=gcc@gcc.gnu.org \
    --cc=richard.guenther@gmail.com \
    --cc=sellcey@cavium.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).