This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: How could I get alias set information from data_reference_p


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.guenther@gmail.com> 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,
>
> ?(*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
>>
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]