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

[Michael Zolotukhin]

Hi Hao,

Thanks for the explanation!

> (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).


Yeah, I've seen that too. This threshold seems pretty low for some loops, but we don't want just to increase it, because it'll increase an overhead on *all* loops. What I've been thinking here though is that if we add a runtime trip-count check, then under this check we can afford having more mem-checks (the trip-count check will gurantee a high trip count, so overhead for these checks would be compensated by vectorizing the loop) . Does it sound sane?

> Actually many of such checks are unnecessary.


Do you have any ideas how can we remove unnecessary checks?

> (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.


I see. I remember some patches on this issue, but they weren't committed, right?

Thanks,
Michael

PS: I'll take another look at the patch soon.


http://reviews.llvm.org/D9368

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