[PATCH] [LoopVectorize]Teach Loop Vectorizer about interleaved memory access

[Hao Liu]

In http://reviews.llvm.org/D9368#167202, @mzolotukhin wrote:

> Hi Hao,
>
> First of all, thanks for working on this!
>  Below is the first round of comments from me, I'll get back to it again to dig into more interesting parts.
>
> BTW, what are the problems that prevents us from getting performance benefits?


Hi Michael,

There are two main issues preventing the loop vectorization in EEMBC.rgbcmy and EEMBC.rgbyiq :
(1) Too many runtime memory checks. If we write "A[i], A[i+1]" in one loop iteration, currently it will compare A[i] and A[i+1] with each other. So if one loop has several reads and writes, the number of runtime memory checks will increase a lot and beyond the threshold (which is currently 8). Actually many of such checks are unnecessary.

(2) The type issue about i8 (AArch64 target specific problem). In AArch64 backend, i8 is illegal. So it will be promoted to i32.

  E.g. char foo(char A) { 
           return A+1;
         }

The IRs in the middle end is like:

  define i8 @foo(i8 %A) #0 {
  entry:
         %conv = zext i8 %A to i32
         %add = add nuw nsw i32 %conv, 1
         %conv1 = trunc i32 %add to i8
          ret i8 %conv1
   }

If a loop has i8 operations, the loop vectorizer will try to vectorize "zext" and "trunc", which cost too much and is not beneficial. The "zext" and "trunc" can not be removed by instcombine as i8 is illegal type, but actually <8 x i8> or <16 x i8> are legal.

If we can fix these two issues, we can get several times of acceleration in such benchmarks.

Another main problem is that my patch will miss many opportunities. The identification is conservative to not break the memory dependence. It can not identify mixed loads/stores. For this issue, I add a TODO in the patch.

Thanks,
-Hao


http://reviews.llvm.org/D9368

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/