<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 25 Feb 2019 at 13:11, Bruce Hoult via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">LLVM has no idea whether the address computed by GEP is actually<br>
within a legal object. The "inbounds" keyword is just you, the<br>
programmer, promising LLVM that you know it's ok and that you don't<br>
care what happens if it is actually out of bounds.<br>
<br>
<a href="https://llvm.org/docs/GetElementPtr.html#what-happens-if-an-array-index-is-out-of-bounds" rel="noreferrer" target="_blank">https://llvm.org/docs/GetElementPtr.html#what-happens-if-an-array-index-is-out-of-bounds</a><br></blockquote><div><br></div><div>Hi Bruce,</div><div><br></div><div>it's not true in general that LLVM has no idea about (or doesn't care about) object sizes. It can infer object size and other things from allocas, global variables, and calls to built-in functions such as malloc(). In the case of Rust we even have an out of tree patch to teach LLVM the same for Rust's (global) heap allocation functions. You can see this information being computed in lib/Analysis/MemoryBuiltins.cpp.<br></div><div><br></div><div>More importantly, the question is *what* actually is being promised to LLVM, more specifically, what the definitions of the terms "out of bounds" and "object" are in this context. It is easy enough to answer intuitively in many specific cases whether a GEP should be considered "out of bounds", but in the cases Ralf described, where offsets and "object sizes" are equal to 0, it is not so clear-cut and depends on tricky matters such as whether zero-sized allocations exist. We (Rust developers) very much care what happens in those cases (it should be a NOP), so it's important to check whether that is compatible with the Rust compiler emitting inbounds GEPs.<br></div><div><br></div><div>It is true that in practice in many cases LLVM won't be able to determine conclusively whether an object exists or not and what its bounds are, but that doesn't answer the question.<br></div><div><br></div><div>Cheers,</div><div>Robin<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On Sun, Feb 24, 2019 at 9:05 AM Ralf Jung via llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
> Hi all,<br>
><br>
> What exactly are the rules for `getelementptr inbounds` with offset 0?<br>
><br>
> In Rust, we are relying on the fact that if we use, for example, `inttoptr` to<br>
> turn `4` into a pointer, we can then do `getelementptr inbounds` with offset 0<br>
> on that without LLVM deducing that there actually is any dereferencable memory<br>
> at location 4. The argument is that we can think of there being a zero-sized<br>
> allocation. Is that a reasonable assumption? Can something like this be<br>
> documented in the LangRef?<br>
><br>
> Relatedly, how does the situation change if the pointer is not created "out of<br>
> thin air" from a fixed integer, but is actually a dangling pointer obtained<br>
> previously from `malloc` (or `alloca` or whatever)? Is getelementptr inbounds`<br>
> with offset 0 on such a pointer a NOP, or does it result in `poison`? And if<br>
> that makes a difference, how does that square with the fact that, e.g., the<br>
> integer `0x4000` could well be inside such an allocation, but doing<br>
> `getelementptr inbounds` with offset 0 on that would fall under the first<br>
> question above?<br>
><br>
> Kind regards,<br>
> Ralf<br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>