[llvm-dev] LoopVectorize fails to vectorize loops with induction variables with PtrToInt/IntToPtr conversions

[Sanjoy Das via llvm-dev]

Hi,

On Tue, Jun 20, 2017 at 5:54 PM, Hal Finkel <hfinkel at anl.gov> wrote:
>>> Whenever I see reports of missed optimization opportunities in the face
>>> of ptrtoint/inttoptr, my first question is: why are these instructions
>>> present in the first place? At the IR level, use of inttoptr is highly
>>> discouraged. Our aliasing analysis, for example, does not look through
>>> them, and so you'll generally see a lot of missed optimizations when
>>> they're around.

+1

> This is exactly what I meant by not being able to create "inbounds" GEPs.
> However, aside from that, I don't recall our semantics restricting the
> formation of "out of bounds" pointers (although there certainly are
> restrictions on the uses of such pointers).

One problem is that there is a difference between (assume A and B are
distinct allocations):

A = i8* some_ptr
B = i8* some_ptr
C = inttoptr(ptrtoint(A) + ptrtoint(B))

and

A = i8* some_ptr
B = i8* some_ptr
C = gep(A, ptrtoint(B))

As far as I know, in the former case C aliases both A and B, where in
the latter case C aliases only A (and not B).

The comment in SCEV is very old, but I suspect it is trying to avoid
accidentally converting the former into the latter via a SCEV creation
-> SCEV expansion step.

-- Sanjoy