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


2009/3/2 Sebastian Pop <sebpop@gmail.com>:
> Thanks Konrad for the patch. ?I'm looking at it, and still I do not
> like the fact that we use the GCC representation for the data
> dependence graph as in:
>
> ? ? ? gimple_stmt_iterator gsi;
> ? ? ? struct data_reference *a, *b;
>
> - ? ? ?for (gsi = gsi_start_bb (GBB_BB (pbb1)); !gsi_end_p (gsi);
> gsi_next (&gsi))
> + ? ? ?for (gsi = gsi_start_bb (GBB_BB (PBB_BLACK_BOX (pbb1)));
> !gsi_end_p (gsi); gsi_next (&gsi))
> ? ? ? ?VEC_safe_push (gimple, heap, stmts, gsi_stmt (gsi));
>
> 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.

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.
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?


>
> Sebastian
>


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