This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][GRAPHITE] More TLC
On Wed, Sep 27, 2017 at 9:33 AM, Richard Biener <rguenther@suse.de> wrote:
> Looks like even when hacking the Fortran FE to produce nested
> ARRAY_REFs we run into the same issue for
>
> (gdb) p debug_data_reference (dr)
> #(Data Ref:
> # bb: 17
> # stmt:
> VIEW_CONVERT_EXPR<real(kind=8)[1:ubound.91][1:ubound.89][1:ubound.87][1:ubound.86]>(*y_117(D))[_24]{lb:
> 1 sz: _20 * 8}[_26]{lb: 1 sz: _21 * 8}[_28]{lb: 1 sz: _22 * 8}[_29]{lb: 1
> sz: 8} = 0.0;
> # ref:
> VIEW_CONVERT_EXPR<real(kind=8)[1:ubound.91][1:ubound.89][1:ubound.87][1:ubound.86]>(*y_117(D))[_24]{lb:
> 1 sz: _20 * 8}[_26]{lb: 1 sz: _21 * 8}[_28]{lb: 1 sz: _22 * 8}[_29]{lb: 1
> sz: 8};
> # base_object:
> VIEW_CONVERT_EXPR<real(kind=8)[1:ubound.91][1:ubound.89][1:ubound.87][1:ubound.86]>(*y_117(D));
> # Access function 0: {1, +, 1}_4
> # Access function 1: (integer(kind=8)) {(unsigned long) stride.88_92, +,
> (unsigned long) stride.88_92}_3;
> # Access function 2: (integer(kind=8)) {(unsigned long) stride.90_96, +,
> (unsigned long) stride.90_96}_2;
> # Access function 3: (integer(kind=8)) {(unsigned long) stride.92_100, +,
> (unsigned long) stride.92_100}_1;
>
> so it looks like simple strided (where stride is a parameter) access
> is not handled either.
Yes, this is the first option I was mentioning: it could work,
could you please make sure that you don't have a bug in the "hack patch"
where the outer dimension should not contain the parameter
(inner array dimension) times the access function.
Example in C:
int A[100][N];
A[i][j] is linearized as *(A + i * N * 4 + j * 4)
and you may have a bug if you delinearized it in the Fortran FE as A[i * N][j]
Could you please check that it would delinearize back to A[i][j]?
>
> GCCs dependence analysis can at least compute distances of two
> DRs when the difference of the access CHRECs is constant. Within
> the polyhedral model those cases cannot be handled?
The difficulty for the polyhedral model is in the representation
of a multiplication of parameter times loop index variable.
The delinearization removes these difficulties by creating linear expressions.
Think about multiplication as something introducing exponentiality
and you realize that any such expression would not fit in the
linear model of polyhedra.
A parameter is nothing else than an outer loop index to which we don't
have access to that loop level as it may be outside the current function
in which we get that parameter in.
Sebastian