[LLVMdev] Canonicalization of ptrtoint/inttoptr and getelementptr

[Dan Gohman]

An object can be allocated at virtual address 5 through extra-VM means (eg.
mmap), and then one can (creatively) interpret the return value of @f as
being associated with whatever %A was associated with *and* 5. The return
value of @g can only be associated with exactly the same set that %A was
associated with. Consequently, it's not always safe to replace @f with @g.

It looks a little silly to say this in the case of the integer constant 5,
and there are some semantic gray areas around extra-VM allocation, but the
same thing happens if the add were adding a dynamic integer value, and then
it's difficult to find a way to separate that case from the constant 5 case.

In any case, the general advice is that people should prefer to use
getelementptr to begin with. LLVM's own optimizers were converted to use
getelementptr instead of ptrtoint+add+inttoptr even when they have to do
raw byte arithmetic.


On Sat, Aug 30, 2014 at 6:01 PM, David Majnemer <david.majnemer at gmail.com>
wrote:

> Consider the two functions bellow:
>
> define i8* @f(i8* %A) {  %pti = ptrtoint i8* %A to i64  %add = add i64
> %pti, 5  %itp = inttoptr i64 %add to i8*  ret i8* %itp}
> define i8* @g(i8* %A) {
>   %gep = getelementptr i8* %A, i64 5  ret i8* %gep}
> What, if anything, prevents us from canonicalizing @f to @g?I've heard
> that this might be in violation of
> http://llvm.org/docs/LangRef.html#pointeraliasing but I don't see how.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140908/6607c0e3/attachment.html>