[PATCH] D16878: [POLLY] Support accesses with differently sized types to the same array

[Johannes Doerfert via llvm-commits]

jdoerfert added a comment.

Regarding the "alignment" test cases:
 I get your point now. The comment in the test cases confused me and the new comment makes it clear why we do not handle these cases _yet_.


================
Comment at: lib/Analysis/ScopInfo.cpp:205
@@ +204,3 @@
+    if (NewElementSize % OldElementSize == 0 &&
+        NewElementSize < OldElementSize) {
+      ElementType = NewElementType;
----------------
cool. I did not find that one.

================
Comment at: lib/Analysis/ScopInfo.cpp:489
@@ +488,3 @@
+  return isl_map_lexmin(getAccessRelation());
+}
+
----------------
I thought so but I cannot find it now.. let's just stick with lexmin. Sorry for the noise.

================
Comment at: test/ScopInfo/multiple-types-non-power-of-two.ll:25
@@ +24,3 @@
+; next multiple of 64.
+
+; The allocation size discussed above defines the number of canonical array
----------------
This does not help. Sorry.

1) In my book i27 consists of more than 3 bytes, thus I do not get the comment. It does not access 4 complete bytes, true, but it accesses more than 3. See point 2) for my take on the modeling.
2) The allocation size is target specific and should not be hard coded in Polly. This means we should not fix the argumentation to byte level. Instead the gcd of the allocation sizes in bit should be used as granularity. This will never make a difference for machines that work on byte level (gcd will just be a multiple of 8) and will prevent problems on machines that do not...


http://reviews.llvm.org/D16878