[llvm-dev] getelementptr inbounds with offset 0
Ralf Jung via llvm-dev
llvm-dev at lists.llvm.org
Mon Feb 25 06:58:32 PST 2019
On 25.02.19 13:10, Bruce Hoult wrote:
> LLVM has no idea whether the address computed by GEP is actually
> within a legal object. The "inbounds" keyword is just you, the
> programmer, promising LLVM that you know it's ok and that you don't
> care what happens if it is actually out of bounds.
The LangRef says I get a poison value when I am violating the bounds. What I am
asking is what exactly this means when the offset is 0 -- what *are* the
conditions under which an offset-by-0 is "out of bounds" and hence yields poison?
Of course LLVM cannot always statically determine this, but it relies on
(dynamically, on the "LLVM abstract machine") such things not happening, and I
am asking what exactly these dynamic conditions are.
> On Sun, Feb 24, 2019 at 9:05 AM Ralf Jung via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>> Hi all,
>> What exactly are the rules for `getelementptr inbounds` with offset 0?
>> In Rust, we are relying on the fact that if we use, for example, `inttoptr` to
>> turn `4` into a pointer, we can then do `getelementptr inbounds` with offset 0
>> on that without LLVM deducing that there actually is any dereferencable memory
>> at location 4. The argument is that we can think of there being a zero-sized
>> allocation. Is that a reasonable assumption? Can something like this be
>> documented in the LangRef?
>> Relatedly, how does the situation change if the pointer is not created "out of
>> thin air" from a fixed integer, but is actually a dangling pointer obtained
>> previously from `malloc` (or `alloca` or whatever)? Is getelementptr inbounds`
>> with offset 0 on such a pointer a NOP, or does it result in `poison`? And if
>> that makes a difference, how does that square with the fact that, e.g., the
>> integer `0x4000` could well be inside such an allocation, but doing
>> `getelementptr inbounds` with offset 0 on that would fall under the first
>> question above?
>> Kind regards,
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
More information about the llvm-dev