[polly] r277263 - Extend the jscop interface to allow the user to declare new arrays and to reference these arrays from access expressions

[Roman Gareev via llvm-commits]

2016-08-11 21:55 GMT+05:00 Michael Kruse <llvm-commits at meinersbur.de>:
> 2016-08-11 17:21 GMT+02:00 Roman Gareev <gareevroman at gmail.com>:
>> Hi Michael,
>>
>> thanks for the comments!
>>
>> 2016-08-10 20:27 GMT+05:00 Michael Kruse <llvm-commits at meinersbur.de>:
>>> 2016-07-30 11:25 GMT+02:00 Roman Gareev via llvm-commits
>>> <llvm-commits at lists.llvm.org>:
>>>
>>>> --- polly/trunk/test/Isl/CodeGen/MemAccess/create_arrays.ll (added)
>>>> +; CHECK:    Arrays {
>>>> +; CHECK:        double E[*][270336][200000]; // Element size 8
>>>
>>>> --- polly/trunk/test/Isl/CodeGen/MemAccess/create_arrays___%bb9---%bb26.jscop (added)
>>>> +      {
>>>> +         "name" : "E",
>>>> +         "sizes" : [ "270336", "200000" ],
>>>> +         "type" : "double"
>>>> +      },
>>>
>>>> +   "statements" : [
>>>> +      {
>>>> +         "accesses" : [
>>>> +            {
>>>> +               "kind" : "read",
>>>> +               "relation" : "{ Stmt_bb12[i0, i1, i2] -> E[i2, i0] }"
>>>> +            },
>>>> +            {
>>>
>>> Hi just noticed some problem here. The array "E" is generated with
>>> three dimensions (with the first one unsized), but the array access is
>>> changed to only a two-dimensional one.
>>
>> Сould we change the array access to three-dimensional one (e.g. "{
>> Stmt_bb12[i0, i1, i2] -> E[0, i2, i0] }")?
>
> Yes, but is it what you intended?

I thought that in this case, it is what we intended.

> The jscop contains sizes of just two
> dimensions. We do not need the size of the outermost dimension in most
> cases, but if you are going to allocate memory for such newly created
> arrays, that size is needed as well.

As far as I know, we decided to just export what -polly-scops -analyze
would print. What sizes would you export in case of a newly created
array to be able to import the generated jscop in future? Should we
additionally store the size of the first dimension?

>
>>> The array's isl_id is named "E" (not "MemRef_E"). We will get a name
>>> clash when introducing an array named "MemRef_A", clashing with the
>>> already existing array A.
>>
>> Could you explain why we get a name clash in this case? I thought that
>> if there is already an array named "A" and we introduce an array named
>> "MemRef_A", a new array named "MemRef_A" will be created.
>
> Assume you have an existing scop that has an array called A. Each
> access will be named "MemRef_A".
>
> Let's create a new array "A" using the JScop (Will there be a clash if
> an array with that name already exists?).

If I'm not mistaken, in this case a new array "A1" will be created.

> To add a reference to it, it
> seems that one has to call the reference also "A". Eg.
>  "{ Stmt_bb12[i0, i1, i2] -> A[i2, i0] }"
>
> Let's create a new array named "MemRef_A". Then we set an array accesses to
>  "{ Stmt_bb12[i0, i1, i2] -> MemRef_A[i2, i0] }"
> Does it now
> 1) refer to the previously existing array "A"
> 2) refer to the newly created array "MemRef_A"
> ????

As far as I understand it now refers to the previously existing array "A".

>> Do you mean that it's better to add prefix "MemRef_" to names of all
>> arrays added in a JSCoP?
>
> Yes.

I thought it would be more intuitive to work with names of isl_ids of
arrays, because they are used to describe, for example, access
relations of JSCoP and arrays of ScopInfos.

OK. If we everyone agrees with it, let's export names of arrays
instead names of their isl_ids.

-- 
                                    Cheers, Roman Gareev.