[PATCH] D20789: Consecutive memory access in Loop Vectorizer - fixed and simplified

[Silviu Baranga via llvm-commits]

Hi Dorit,

> -----Original Message-----
> From: Dorit Nuzman [mailto:dorit.nuzman at intel.com]
> Sent: 03 September 2016 23:11
> To: elena.demikhovsky at intel.com; hfinkel at anl.gov; ayal.zaks at intel.com;
> mzolotukhin at apple.com; mkuper at google.com; anemet at apple.com
> Cc: dorit.nuzman at intel.com; wmi at google.com; Silviu Baranga;
> sanjoy at playingwithpointers.com; shirokiyroman at yandex.ru;
> mssimpso at codeaurora.org; junbuml at codeaurora.org; llvm-
> commits at lists.llvm.org
> Subject: Re: [PATCH] D20789: Consecutive memory access in Loop Vectorizer
> - fixed and simplified


> Both cases will end up generating similar runtime pointer-range comparison…
> why are we not concerned with wrapping in the first?

I think this might be a bug? I don’t think we would be able to perform bound checks
for wrapping pointers - our checking code just wouldn't work in this case (although if
we really need to we could check at run-time that a pointer doesn't wrap).

> 
> And when ShouldCheckWrap is true: I assume the unit stride restriction in
> isNoWrap comes from the concern not to refer to an address beyond the
> location of the first element past the array boundary? Is that because we
> compute the pointer range as "ptr+Stride*TripCount", which might refer to
> "Stride" locations past the array boundary (and therefore may wrap around
> the address space)?

This might be a trick to prove no wrap (see the comments in getPtrStride).
Interestingly, getPtrStride would check if the pointer wraps anyway so this
stride restriction shouldn't be needed.

Cheers,
Silviu

> 
> thanks!
> Dorit
> 
> 
> Repository:
>   rL LLVM
> 
> https://reviews.llvm.org/D20789
> 
>