I think it’s reasonable to expect that IR generated by frontends doesn’t do this.
Not sure about transforms; I can imagine that we might speculate a load without proving all the bits are well-defined.
On 9/21/20 12:32 PM, Eli Friedman via llvm-dev wrote:
> I think it’s reasonable to expect that IR generated by frontends doesn’t do this.
> Not sure about transforms; I can imagine that we might speculate a load without proving all the bits are well-defined.
> From: llvm-dev <llvm-dev...@lists.llvm.org> On Behalf Of Juneyoung Lee via llvm-dev
> Sent: Sunday, September 20, 2020 3:54 PM
> To: llvm-dev <llvm...@lists.llvm.org>
> Subject: [EXT] Re: [llvm-dev] Is it valid to dereference a pointer that have undef bits in its offset?
>> %p2 = gep %p, (undef & 8)
> A silly typo: undef & 8 -> undef & 7
> On Mon, Sep 21, 2020 at 7:47 AM Juneyoung Lee <juneyo...@sf.snu.ac.kr<mailto:juneyo...@sf.snu.ac.kr>> wrote:
> Hello all,
> Is it valid to dereference a pointer that has undef bits in its offset?
> For example,
> %p = alloca [8 x i8]
> %p2 = gep %p, (undef & 8)
> store 0, %p2
> undef & 8 is always less than 8, so technically it will store zero to one of the array's elements.
> The reason is that I want to improve no-undef analysis by suggesting that a pointer that is passed to load/store is well-defined, by making it raise UB when a pointer with undef bits is given.
> A suggested patch is here: https://reviews.llvm.org/D87994
> I wonder whether there is a case using this to do something that I'm not aware.
> Juneyoung Lee
> Software Foundation Lab, Seoul National University
> LLVM Developers mailing list
LLVM Developers mailing list
Or to say it differently, I think it's reasonable for %p2 and %p3 to be
provably no alias and dereferenceable, and for %v and %v2 to be safe to
%p = alloca [16 x i8]
%p2 = gep %p, (undef & 7)
%v = load %p2
%p3 = gep %p, 8
%v2 = load %p3
Keep in mind that the undef doesn't have to be literal and can be
arbitrarily obscured (e.g. behind a function call). The alternative
interpretation is extremely limiting.
> Another concern is then, how can we efficiently encode an assumption that a
> pointer variable in IR does not have undef bits?
> Certainly, in the front-end language, (most of) pointers won't have undef
> bits, and it would be great if the information is still available in IR.
> A pointer argument can be encoded using noundef, but, e.g., for a pointer
> that is loaded from memory, such information disappears.
> I think this information is helpful reducing the cost of fixing existing
> undef/poison-related optimizations, because we can conclude that we don't
> need to insert freeze in more cases.
I thought we solved that already:
`call void llvm.assume(i1 true) ["noundef"(type* %ptr),
Is that enough for your needs?