[PATCH] [Polly] Introduce the ScopArrayInfo class.

Tobias Grosser tobias at grosser.es
Sat Oct 4 23:47:53 PDT 2014

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.

I also looked at the new patch and do not have any further comments. I 
think it is good to commit otherwise.


More information about the llvm-commits mailing list