Juneyoung Lee via llvm-dev
2020-Sep-20 22:47 UTC
[llvm-dev] Is it valid to dereference a pointer that have undef bits in its offset?
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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200921/9a03c974/attachment.html>
Juneyoung Lee via llvm-dev
2020-Sep-20 22:54 UTC
[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> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200921/2d80580d/attachment.html>
Eli Friedman via llvm-dev
2020-Sep-21 17:32 UTC
[llvm-dev] Is it valid to dereference a pointer that have undef bits in its offset?
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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200921/ffb8695f/attachment-0001.html>