[llvm-dev] Is it valid to dereference a pointer that have undef bits in its offset?

[Johannes Doerfert via llvm-dev]

My feeling tells me we should allows this.
No proper justification handy but your example doesn't strike me as UB.

~ Johannes


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.
>
> -Eli
>
> From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Juneyoung Lee via llvm-dev
> Sent: Sunday, September 20, 2020 3:54 PM
> To: llvm-dev <llvm-dev at 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 <juneyoung.lee at sf.snu.ac.kr<mailto:juneyoung.lee at 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.
>
> Thanks,
> Juneyoung
>
>
> --
>
> Juneyoung Lee
> Software Foundation Lab, Seoul National University
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev