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

Mikhail Maltsev via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Oct 2 10:46:16 PDT 2019


miyuki added a comment.

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
  }

> 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





More information about the llvm-commits mailing list