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

Roman Lebedev via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sun Oct 13 01:33:52 PDT 2019


lebedev.ri added a comment.

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

> > So clang is perfectly correct here.
>
> Yes, Clang is correct. EmitGEPOffset is doing the wrong thing.
>  `nuw` is incorrect because negative offsets are allowed. `nsw` would also be incorrect because of the quote you mentioned before:
>
> > 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. <...>
>
> `nsw` would imply that signed overflow must not occur when computing the offset in the integer type of the same width as the pointer type. But LangRef is talking about infinitely precise arithmetic.


I'll rephrase.
I don't think this case is defined for address space 0 - i don't believe you can ever have an object e.g. occupying `[i8 128, i8 8]` (i.e. including null pointer).
It it likely not so for other address spaces. So the likely solution is to use `NSW` iff address space = 0.


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