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: Documentation for loop infrastructure



Sebastian Pop <sebastian.pop@cri.ensmp.fr> wrote on 08/09/2006 18:04:01:

> Ira Rosen wrote:
> >
> > > Here is the documentation for the data dependence analysis.
> >
> > I can add a description of data-refs creation/analysis if it is useful.
> >
>
> That's a good idea, thanks.
>
> Sebastian

Here it is.
Ira

> The data references are discovered in a particular order during the
> scanning of the loop body: the loop body is analyzed in execution
> order, and the data references of each statement are pushed at the end
> of the data reference array.  Two data references syntactically occur
> in the program in the same order as in the array of data references.
> This syntactic order is important in some classical data dependence
> tests, and mapping this order to the elements of this array avoids
> costly queries to the loop body representation.

Three types of data references are currently handled: ARRAY_REF,
INDIRECT_REF and COMPONENT_REF. The data structure for the data reference
is @code{data_reference}, where @code{data_reference_p} is a name of a
pointer to the data reference structure. The structure contains the
following elements:

@itemize
@item @code{base_object_info}: Provides information about the base object
of the data reference and its access functions. These access functions
represent the evolution of the data reference in the loop relative to
its base, in keeping with the classical meaning of the data reference
access function for the support of arrays. For example, for a reference
@code{a.b[i][j]}, the base object is @code{a.b} and the access functions,
one for each array subscript, are:
@code{@{i_init, + i_step@}_1, @{j_init, +, j_step@}_2}.

@item @code{first_location_in_loop}: Provides information about the first
location accessed by the data reference in the loop and about the access
function used to represent evolution relative to this location. This data
is used to support pointers, and is not used for arrays (for which we
have base objects). Pointer accesses are represented as a one-dimensional
access that starts from the first location accessed in the loop. For
example:

@smallexample
      for i
         for j
          *((int *)p + i + j) = a[i][j];
@end smallexample

The access function of the pointer access is @code{@{0, + 4B@}_2} relative
to @code{p + i}. The access functions of the array are
@code{@{i_init, + i_step@}_1} and @code{@{j_init, +, j_step@}_2} relative
to @code{a}.

Usually, the object the pointer refers to is either unknown, or we canât
prove that the access is confined to the boundaries of a certain object.

Two data references can be compared only if at least one of these two
representations has all its fields filled for both data references.

The current strategy for data dependence tests is as follows:
If both @code{a} and @code{b} are represented as arrays, compare
@code{a.base_object} and @code{b.base_object};
if they are equal, apply dependence tests (use access functions based on
base_objects).
Else if both @code{a} and @code{b} are represented as pointers, compare
@code{a.first_location} and @code{b.first_location};
if they are equal, apply dependence tests (use access functions based on
first location).
However, if @code{a} and @code{b} are represented differently, only try
to prove that the bases are definitely different.

@item Aliasing information.
@item Alignment information.
@end itemize

> The structure describing the relation between two data references is
> @code{data_dependence_relation} and the shorter name for a pointer to
> such a structure is @code{ddr_p}.  This structure contains:

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