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

Johannes Doerfert via llvm-commits llvm-commits at lists.llvm.org
Thu Feb 4 02:49:37 PST 2016


jdoerfert added a comment.

I generally like this idea but I still think the distinction between the last two test cases is not justified at all. All char pointers could have an arbitrary initial alignment in the last test case and it is in general not a problem to have unaligned accesses. This patch prevents some unaligned accesses from being represented but allows less obvious ones anyway.


================
Comment at: include/polly/Support/ScopHelper.h:151
@@ -141,1 +150,3 @@
+  }
+
   llvm::Value *getValueOperand() const {
----------------
Can we use this somewhere else too? If so we might want to do so and commit it ahead of time.

================
Comment at: lib/Analysis/ScopInfo.cpp:205
@@ +204,3 @@
+  return ValA;
+}
+
----------------
Maybe you can use:

```
  APInt GreatestCommonDivisor (const APInt &Val1, const APInt &Val2)
```

or 

```
  std::experimental::gcd
```

from here http://en.cppreference.com/w/cpp/experimental/gcd .


================
Comment at: lib/Analysis/ScopInfo.cpp:496
@@ +495,3 @@
+  return isl_map_lexmin(getAccessRelation());
+}
+
----------------
Shouldn't the structute allow us to look for the lower bound instead of the lexmin?

================
Comment at: test/ScopInfo/multiple-types-non-power-of-two.ll:24
@@ +23,3 @@
+; not rounded up to the next power-of-two allocation size, but rather to the
+; next multiple of 64.
+
----------------
I do not get the part about the allocation sizes. Where do you verify them in this test case?

================
Comment at: test/ScopInfo/multiple-types-unaligned.ll:5
@@ +4,3 @@
+;    // The following statements are not aligned to a multiple of the
+;    // type size.
+;    void multiple_types(char *Short, char *Float, char *Double) {
----------------
You don't know that. Same as you don't know that they are in the example below. As long as there is no alignment information attached to the pointers it is not clear how the alignment is and how it has to be in order to access the memory through this pointers. Not all machines require aligned accesses...


http://reviews.llvm.org/D16878





More information about the llvm-commits mailing list