[PATCH] D68342: [Analysis] Don't assume that overflow can't happen in EmitGEPOffset

[Roman Lebedev via Phabricator via llvm-commits]

lebedev.ri added a comment.

In D68342#1691704 <https://reviews.llvm.org/D68342#1691704>, @miyuki wrote:

> In D68342#1691617 <https://reviews.llvm.org/D68342#1691617>, @lebedev.ri wrote:
>
> > I'm not fully convinced this is correct, as per
> >  https://llvm.org/docs/LangRef.html#getelementptr-instruction
> >
> >   If the inbounds keyword is present, the result value of the getelementptr is a poison value
> >   if the base pointer is not an in bounds address of an allocated object, or if any of the
> >   addresses that would be formed by successive addition of the offsets implied by the indices
> >   to the base address with infinitely precise signed arithmetic are not an in bounds address
> >   of that allocated object. <...>
> >
>
>
> I also thought that "in bounds address of an allocated object" has something to do with the type used in the GEP instruction, but that's not how Clang interprets it.
>  E.g. for the following code
>
>   int read(int *buf) {
>     buf -= 2;
>     return *buf;
>   }
>   
>
> It generates the following:
>
>   define dso_local i32 @_Z4readPi(i32* nocapture readonly %buf) local_unnamed_addr #0 {
>   entry:
>     %add.ptr = getelementptr inbounds i32, i32* %buf, i64 -2
>     %0 = load i32, i32* %add.ptr, align 4, !tbaa !2
>     ret i32 %0
>   }


I do not understand this point, could you elaborate please?

>> At worst `NUW` should be relaxed to `NSW`.
> 
> What about the case I mentioned, i.e. an object which is larger than half of its address space?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D68342/new/

https://reviews.llvm.org/D68342