This is the mail archive of the gcc-patches@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: [graphite] data dependence analysis revival


On Mon, Mar 2, 2009 at 23:24, Konrad Trifunovic
<konrad.trifunovic@gmail.com> wrote:
>> We should record a data dependence relation on a tuple of poly_bb's
>> not on gimple statements. ?Data dependence analysis should be
>> completely independent of GCC data structures.
>
> I agree. So far, we have data structure called:
>
> struct data_dependence_polyhedron
> {
> ?struct data_reference *a;
> ?struct data_reference *b;
> ?bool reversed_p;
> ?bool loop_carried;
> ?signed level;
> ?CloogDomain *polyhedron;
> };
>
> this one has fields for the source (a) and sink (b) data references of
> the dependence.
> I suggest to replace 'a' and 'b' with pointer to polyhedral BB's.
>

No.  We should have a structure poly_dr that contains a pointer not to
a gimple stmt but a pointer to a poly_bb.

> Though one problem might arise:
> we can have multiple dependences between the same pair of basic
> blocks: those dependences
> are between some pairs of data references that belong to same basic
> blocks. If we do not keep
> pointer to source and sink data references, we loose that information.

If we have a poly_dr struct we will not lose this information.

> This opens up a new discussion: how to represent data references
> (array references) in a way that
> is not tied up to GIMPLE representation. Use PCP types?
>

We will have to clean up the data_reference struct as we did cleaned
up the scop and graphite_bb data structures: get the polyhedral part
separated from the GCC part for the data_reference structure.

PCP will come later in the play, and so we will have to have the data
reference and dependence relations structures ready with no links to
the GCC representation in it.

Sebastian


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