[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