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: Bin Cheng <Bin.Cheng@arm.com>,
	"gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH PR69489/01]Improve tree ifcvt by storing/tracking DR against its innermost loop bahavior if possible
Date: Wed, 16 Mar 2016 16:17:00 -0000	[thread overview]
Message-ID: <CAHFci28h8NsSHkVoLmB1kr1EtVoca8a0X3ocvk_WDd0ynN2v6A@mail.gmail.com> (raw)
In-Reply-To: <CAFiYyc3-6ua2+uXMpEL_x5xp8bxp-Qrke8EFhHzFKQ6bqmeVdw@mail.gmail.com>

On Wed, Mar 16, 2016 at 12:20 PM, Richard Biener
<richard.guenther@gmail.com> wrote:
>
> On Wed, Mar 16, 2016 at 10:59 AM, Bin Cheng <Bin.Cheng@arm.com> wrote:
> > Hi,
> > ......
> > Bootstrap and test on x86_64 and AArch64.  Is it OK, not sure if it's GCC 7?
>
> Hmm.
Hi,
Thanks for reviewing.
>
> +  equal_p = true;
> +  if (e1->base_address && e2->base_address)
> +    equal_p &= operand_equal_p (e1->base_address, e2->base_address, 0);
> +  if (e1->offset && e2->offset)
> +    equal_p &= operand_equal_p (e1->offset, e2->offset, 0);
>
> surely better to return false early.
>
> I think we don't want this in tree-data-refs.h also because of ...
>
> @@ -615,15 +619,29 @@
> hash_memrefs_baserefs_and_store_DRs_read_written_info
> (data_reference_p a)
>    data_reference_p *master_dr, *base_master_dr;and REALPART) before creating the DR (or adjust the equality function
and hashing
>    tree ref = DR_REF (a);
>    tree base_ref = DR_BASE_OBJECT (a);
> +  innermost_loop_behavior *innermost = &DR_INNERMOST (a);
>    tree ca = bb_predicate (gimple_bb (DR_STMT (a)));
>    bool exist1, exist2;
>
> -  while (TREE_CODE (ref) == COMPONENT_REF
> -        || TREE_CODE (ref) == IMAGPART_EXPR
> -        || TREE_CODE (ref) == REALPART_EXPR)
> -    ref = TREE_OPERAND (ref, 0);
> +  /* If reference in DR has innermost loop behavior and it is not
> +     a compound memory reference, we store it to innermost_DR_map,
> +     otherwise to ref_DR_map.  */
> +  if (TREE_CODE (ref) == COMPONENT_REF
> +      || TREE_CODE (ref) == IMAGPART_EXPR
> +      || TREE_CODE (ref) == REALPART_EXPR
> +      || !(DR_BASE_ADDRESS (a) || DR_OFFSET (a)
> +          || DR_INIT (a) || DR_STEP (a) || DR_ALIGNED_TO (a)))
> +    {
> +      while (TREE_CODE (ref) == COMPONENT_REF
> +            || TREE_CODE (ref) == IMAGPART_EXPR
> +            || TREE_CODE (ref) == REALPART_EXPR)
> +       ref = TREE_OPERAND (ref, 0);
> +
> +      master_dr = &ref_DR_map->get_or_insert (ref, &exist1);
> +    }
> +  else
> +    master_dr = &innermost_DR_map->get_or_insert (innermost, &exist1);
>
> we don't want an extra hashmap but replace ref_DR_map entirely.  So we'd need to
> strip outermost non-variant handled-components (COMPONENT_REF, IMAGPART
> and REALPART) before creating the DR (or adjust the equality function
> and hashing
> to disregard them which means subtracting their offset from DR_INIT.
I am not sure if I understand correctly.  But for component reference,
it is the base object that we want to record/track.  For example,

  for (i = 0; i < N; i++) {
    m = *data++;

    m1 = p1->x - m;
    m2 = p2->x + m;

    p3->y = (m1 >= m2) ? p1->y : p2->y;

    p1++;
    p2++;
    p3++;
  }
We want to infer that reads of p1/p2 in condition statement won't trap
because there are unconditional reads of the structures, though the
unconditional reads are actual of other sub-objects.  Here it is the
invariant part of address that we want to track.
Also illustrated by this example, we can't rely on data-ref analyzer
here.  Because in gathering/scattering cases, the address could be not
affine at all.
>
> To adjust the references we collect you'd maybe could use a callback
> to get_references_in_stmt
> to adjust them.
>
> OTOH post-processing the DRs in if_convertible_loop_p_1 can be as simple as
Is this a part of the method you suggested above, or is it an
alternative one?  If it's the latter, then I have below questions
embedded.
>
> Index: tree-if-conv.c
> ===================================================================
> --- tree-if-conv.c      (revision 234215)
> +++ tree-if-conv.c      (working copy)
> @@ -1235,6 +1220,38 @@ if_convertible_loop_p_1 (struct loop *lo
>
>    for (i = 0; refs->iterate (i, &dr); i++)
>      {
> +      tree *refp = &DR_REF (dr);
> +      while ((TREE_CODE (*refp) == COMPONENT_REF
> +             && TREE_OPERAND (*refp, 2) == NULL_TREE)
> +            || TREE_CODE (*refp) == IMAGPART_EXPR
> +            || TREE_CODE (*refp) == REALPART_EXPR)
> +       refp = &TREE_OPERAND (*refp, 0);
> +      if (refp != &DR_REF (dr))
> +       {
> +         tree saved_base = *refp;
> +         *refp = integer_zero_node;
> +
> +         if (DR_INIT (dr))
> +           {
> +             tree poffset;
> +             int punsignedp, preversep, pvolatilep;
> +             machine_mode pmode;
> +             HOST_WIDE_INT pbitsize, pbitpos;
> +             get_inner_reference (DR_REF (dr), &pbitsize, &pbitpos, &poffset,
> +                                  &pmode, &punsignedp, &preversep, &pvolatilep,
> +                                  false);
> +             gcc_assert (poffset == NULL_TREE);
> +
> +             DR_INIT (dr)
> +               = wide_int_to_tree (ssizetype,
> +                                   wi::sub (DR_INIT (dr),
> +                                            pbitpos / BITS_PER_UNIT));
> +           }
> +
> +         *refp = saved_base;
> +         DR_REF (dr) = *refp;
> +       }
Looks to me the code is trying to resolve difference between two (or
more) component references, which is DR_INIT in the code.  But DR_INIT
is not the only thing needs to be handled.  For a structure containing
two sub-arrays, DR_OFFSET may be different too.
Actually I did try to replace ref_DR_map.  For memory reference
doesn't have innermost affine behavior, we need to modify DR fields by
populating it with artificial data.  This results in some kind of
over-designed code.  IMHO, modifying some DR structures outside of
data-ref analyzer isn't that good.  After comparing the two methods, I
think may be this one is better, of course with the cost of two
different maps.

I might be misunderstanding your idea, so please correct if I was wrong.

Thanks,
bin
> +
>        dr->aux = XNEW (struct ifc_dr);
>        DR_BASE_W_UNCONDITIONALLY (dr) = false;
>        DR_RW_UNCONDITIONALLY (dr) = false;
>
>
> Can you add a testcase for the vectorization?
>
> Richard.
>

  reply	other threads:[~2016-03-16 16:17 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-16 10:00 Bin Cheng
2016-03-16 12:20 ` Richard Biener
2016-03-16 16:17   ` Bin.Cheng [this message]
2016-03-17  9:53     ` Richard Biener
     [not found]       ` <CAHFci29CHpOBxah4QxrL_JOL6p_NC=r3-e3eoNjHp_4z749PnQ@mail.gmail.com>
2016-03-28 22:04         ` Fwd: " Bin.Cheng
2016-03-29  8:44           ` Richard Biener
2016-03-31 17:08             ` Bin.Cheng
2016-04-04 13:07               ` Richard Biener
2016-04-04 14:14                 ` Bin.Cheng
2016-04-05  7:23                   ` 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=CAHFci28h8NsSHkVoLmB1kr1EtVoca8a0X3ocvk_WDd0ynN2v6A@mail.gmail.com \
    --to=amker.cheng@gmail.com \
    --cc=Bin.Cheng@arm.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).