public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Tobias Grosser <grosser@fim.uni-passau.de>
To: Richard Guenther <richard.guenther@gmail.com>
Cc: Sebastian Pop <sebpop@gmail.com>, Li Feng <nemokingdom@gmail.com>,
	GCC <gcc@gcc.gnu.org>
Subject: Re: How could I get alias set information from data_reference_p
Date: Wed, 15 Jul 2009 11:02:00 -0000	[thread overview]
Message-ID: <1247655619.1418.179.camel@localhost> (raw)
In-Reply-To: <84fc9c000907141434n18721235oddafd9ff5489ff72@mail.gmail.com>

On Tue, 2009-07-14 at 23:34 +0200, Richard Guenther wrote:
> On Tue, Jul 14, 2009 at 6:08 PM, Sebastian Pop<sebpop@gmail.com> wrote:
> > On Tue, Jul 14, 2009 at 11:03, Sebastian Pop<sebpop@gmail.com> wrote:
> >>> Why do you need alias-set numbers?
> >>
> >> We want to represent the alias set information as an extra subscript
> >> on memory accesses: for example,
> >>
> >> if we have A[10] and supposing that A is in alias set 6, this would be
> >> represented as "memory_access[6][10]".
> >>
> >> For B[3][4] with base array B in alias set 7 and 8, we would represent
> >> this as "memory_access[7][3][4] or memory_access[8][3][4]".
> >>
> >> The data dependence test that we currently have in the graphite branch
> >> would work with alias sets represented by an extra dimension to the
> >> array dimensions.
> >
> > And by the way, right now we consider that all the data refs alias each
> > other, that means that we set the alias dimension of the memory
> > accesses to 1 for every data reference.  This makes the test very
> > conservative: in the example above, with the current implementation,
> > we would have:
> >
> > A: memory_access[1][10]
> > B: memory_access[1][3][4]
> 
> Well, so you really want to have sort-of the base objects partitioned
> into must(!)-conflict sets?  Thus,

Is there anything like must-conflict? I thought the alias oracle just
returns may conflict relations.
This information should be passed to graphite without loosing any
information.

>   (*p)[1][2]
>   (*q)[1][3]
> 
> is only correct if the resulting accesses may not alias?  (that is,
> p == q?)

What do you mean by is correct?

> 
> No, we don't have such information readily available.  You have
> to compute it.  Likely by building a complete conflict map of
> the bases of all memory references and partitioning it.
> 
> Which doesn't sound like a great idea - it's quadratic.  Thus, can't
> you represent this in a more sparse way?

It is quadratic in what? In the number of data references?

If the only way we can get the information if two data references may
alias is asking the oracle, I do not think there is an alternative. We
have to get at least this information. So there will be nb_of_drs^2
calls to the alias oracle. Or is there any alternative?

I think the only way to get to less complexity is to limit the
information passed to graphite. E.g. we can put everything in the same
alias set as we do now. This is very conservative but definitely faster.

I tend to take the high complexity at the moment, as I do not think we
get many SCoPs that are too big to handle and passing all the details
allows Graphite to do more optimizations. However we can switch to the
old approach if the number of data references passes a certain limit, so
gcc's speed will not suffer.

Tobi


  parent reply	other threads:[~2009-07-15 11:02 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-14  6:01 Li Feng
2009-07-14  8:54 ` Richard Guenther
2009-07-14  9:12   ` Li Feng
2009-07-14  9:40     ` Richard Guenther
2009-07-14 15:14       ` Sebastian Pop
2009-07-14 15:26         ` Richard Guenther
2009-07-14 16:03           ` Sebastian Pop
2009-07-14 16:09             ` Sebastian Pop
2009-07-14 21:34               ` Richard Guenther
2009-07-15  7:59                 ` Li Feng
2009-07-15 11:02                 ` Tobias Grosser [this message]
2009-07-15 11:26                   ` Richard Guenther
2009-07-15 19:16                     ` Tobias Grosser
2009-07-15 20:46                       ` Richard Guenther
2009-07-15 20:49                         ` Richard Guenther
     [not found]                         ` <15137_1247690941_4A5E40BC_15137_586_1_84fc9c000907151348s41395cc5u6cfacb60cde78bfa@mail.gmail.com>
2009-07-15 23:16                           ` Tobias Grosser
2009-07-16  8:39                             ` Richard Guenther
2009-07-16  9:00                               ` Li Feng
2009-07-16  9:16                                 ` Richard Guenther
2009-07-16 15:45                                 ` Daniel Berlin
2009-07-16 16:04                                   ` Sebastian Pop
2009-07-17  1:36                                   ` Li Feng

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=1247655619.1418.179.camel@localhost \
    --to=grosser@fim.uni-passau.de \
    --cc=gcc@gcc.gnu.org \
    --cc=nemokingdom@gmail.com \
    --cc=richard.guenther@gmail.com \
    --cc=sebpop@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).