Hi Richard, Maybe you could look into this thread and give us some suggestion/confirmation. Now we plan to use dr_may_alias_p (DR1, DR2) to partition the alias set. http://groups.google.de/group/gcc-graphite/browse_thread/thread/7bffbe9037b5adf4?hl=en
Thanks, Li On Wed, Jul 15, 2009 at 5:34 AM, Richard Guenther<richard.guent...@gmail.com> wrote: > On Tue, Jul 14, 2009 at 6:08 PM, Sebastian Pop<seb...@gmail.com> wrote: >> On Tue, Jul 14, 2009 at 11:03, Sebastian Pop<seb...@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, > > (*p)[1][2] > (*q)[1][3] > > is only correct if the resulting accesses may not alias? (that is, > p == q?) > > 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? > > Richard. > >> Sebastian >> >
