[PATCH] D37419: Teach scalar evolution to handle inttoptr/ptrtoint

[Daniel Berlin via llvm-commits]

>
>
> > I also don't understand "  // It's tempting to handle inttoptr and
> ptrtoint
> > as no-ops, however this can
> >   // lead to pointer expressions which cannot safely be expanded to GEPs,
> >   // because ScalarEvolution doesn't respect the GEP aliasing rules when
> >   // simplifying integer expressions."
> >
> > 1. What are "the gep aliasing rules", exactly?
> > https://llvm.org/docs/LangRef.html#pointeraliasing does not mention
> special
> > rules for gep :)
>
> I think the rule it is talking about is that reads and writes on a GEP
> are allowed to only read from and write to the allocation that is
> passed in as the first parameter to the GEP

When we had the discussion about "inrange" and "inbounds", (and elsewhere,
like field accesses) it was raised repeatedly that it's just fine to gep
outside what would be the normal "range" of a pointer, because you can't
ever really tell what it is.
IE a gep of a given pointer can access anything it wants.

In fact, it seemed generally accepted that you can happily GEP from a
pointer to anywhere you want unless there's an inrange or inbounds on it.
So i'm not sure what you mean by "the allocation", since none of these
allocations are  defined in terms of llvm memory semantics (IE they aren't
alloca's, they are malloc/frees).
If that's not the case, we are not being consistent (IE we're losing
optimizations we shouldn't, and we have correctness issues we don't think
we do).

-- you can't GEP from one
> allocation to another different allocation and issue reads/writes.

So
> my statement above was imprecise, `%p0` no-alias `%p1` is not
> sufficient to infer no-alias in the GEP case, you'd have to know that
> `%p0` and `%p1` are different allocations (based off different malloc
> or alloca, for instance).





>
> I think the pointer aliasing rules have a typo (which I'll fix), but
> in principle this follows from:
>
> "Any memory access must be done through a pointer value associated
> with an address range of the memory access, otherwise the behavior is
> undefined. Pointer values are associated with address ranges according
> to the following rules"
>


>
> "A pointer value is associated with the addresses associated with any
> value it is based on."
>
> "A pointer value formed from a getelementptr operation is based on the
> second [should be *first*] value operand of the getelementptr."
>


This set of rules, without anything more, implies we have both correcntess
and optimization issues :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170903/bdde05d7/attachment.html>