[PATCH] [Polly] Introduce the ScopArrayInfo class.

Johannes Doerfert doerfert at cs.uni-saarland.de
Sun Oct 5 04:32:48 PDT 2014

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 ;)

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

> Tobias


Johannes Doerfert
Researcher / PhD Student

Compiler Design Lab (Prof. Hack)
Saarland University, Computer Science
Building E1.3, Room 4.26

Tel. +49 (0)681 302-57521 : doerfert at cs.uni-saarland.de
Fax. +49 (0)681 302-3065  : http://www.cdl.uni-saarland.de/people/doerfert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 213 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141005/52a1db0f/attachment.sig>

More information about the llvm-commits mailing list