[PATCH] [Polly] Introduce the ScopArrayInfo class.

[Tobias Grosser]

On 05/10/2014 13:32, Johannes Doerfert wrote:
> On 10/05, Tobias Grosser wrote:
>> On 04/10/2014 16:28, Johannes Doerfert wrote:
>>> Responses. I would try to change the code according to the comments but I still like the changes to the tests ({{(i32}i64)}} instread of i32)
>>
>> Thanks for the responses.
>>
>>> grosser wrote:
>>>> It is unclear to me why this test case needs to be modified and especially why the generated IR now can be have one of two forms. Is the IR we generate not supposed to be predictable?
>>> It has a different form now because for A[100]
>>>    CreateBitcast(A[0]) == yields ==> getelemenptr inbounds [100 x i32]* @A, i32 0, i32 0
>>> where the indices are of type i32.
>>>
>>> Before the patch we added the indices and used the typ of the only real index op to create "zeros" (thus they were i64). Now I don't want to hardcode i32 because a change in the bitcast function or in our code could revert this or mix the indice types **without** a semantical change, thus I don't see the reason to fix one type here.
>>
>> OK. Thanks for explaining. I agree that it does not make a semantic
>> difference if the zero offset is of type i32 or i64. As the reason for this
>> change was not obvious to me, maybe it is worth a short comment in the
>> commit message.
>>
>> Also, to my understanding the last operand can only be i64 as the add
>> instruction where the operand comes from has this type. So maybe here the
>> i32|i64 is not needed.
> Your right. I'll change it but it would have been a minor mistake ;)

Thanks, like this in the future people do not need to spend time 
thinking about this.

Tobias