[llvm-dev] Semantics of any out-of-bounds address returned by GEP

[Michael Kruse via llvm-dev]

Am Di., 7. Jan. 2020 um 00:37 Uhr schrieb Gautam Chakrabarti via
llvm-dev <llvm-dev at lists.llvm.org>:
> However, https://llvm.org/docs/GetElementPtr.html#how-is-gep-different-from-ptrtoint-arithmetic-and-inttoptr says:
>
>
>
> “Also, GEP carries additional pointer aliasing rules. It’s invalid to take a GEP from one object, address into a different separately allocated object, and dereference it. IR producers (front-ends) must follow this rule, and consumers (optimizers, specifically alias analysis) benefit from being able to rely on it.”
>
>
>
> This quite clearly says the out-of-bounds address shall not be dereferenced through. This also seems to be the assumption in AliasAnalysis implementation (as already stated in above documentation).

I think this is not a property of the GEP instruction, but pointer
provenance [1]. Basically, compilers can assume that the result of
arithmetic on pointers to a memory object (e.g. malloc or allocation
or stack variable) will still point to the same memory object.

[1] https://blog.regehr.org/archives/1621

Michael