search for: __locally__

Hi Bruce, 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. > >

...nds %P 0 The first happens in Rust all the time, and we rely on not getting poison. The second doesn't occur in Rust (to my knowledge), but it seems somewhat inconsistent to return poison in one case and not the other. Kind regards, Ralf > A side-effect based on the GEP > will however __locally__ introduce an dereferencability assumption (in > my opinion at least). Let's say the code looks like this: > > > %G = gep inbounds (int2ptr 4) 0 > ; We don't know anything about the dereferencability of > ; the memory at address 4 here. > br %cnd, %BB0, %BB1 &g...

...ut also, your response assumes "dangling pointers are undef/posion", which is new to me. I'd be rather shocked if this is something LLVM actually relies on anywhere. Kind regards, Ralf > > Cheers, > Johannes > >>> A side-effect based on the GEP will however __locally__ introduce an >>> dereferencability assumption (in my opinion at least). Let's say the >>> code looks like this: >>> >>> >>> %G = gep inbounds (int2ptr 4) 0 ; We don't know anything about the >>> dereferencability of ; the memory at a...

...If GEPi does something, it will make the *output* poison (%G2), but you are saying the *input* becomes poison (%P1), and that cannot be a consequence of GEPi at all. Kind regards, Ralf > > Cheers, > Johannes > > >>>>> A side-effect based on the GEP will however __locally__ introduce an >>>>> dereferencability assumption (in my opinion at least). Let's say the >>>>> code looks like this: >>>>> >>>>> >>>>> %G = gep inbounds (int2ptr 4) 0 ; We don't know anything about the >>>&...