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>
Johannes Doerfert via llvm-dev
2020-Sep-21 17:41 UTC
[llvm-dev] Is it valid to dereference a pointer that have undef bits in its offset?
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
Philip Reames via llvm-dev
2020-Sep-21 18:41 UTC
[llvm-dev] Is it valid to dereference a pointer that have undef bits in its offset?
I think we need to allow this. Otherwise, we have to prove that addresses are non-undef before we can hoist or sink a memory instruction. Today, aliasing can use things like known bits, and if we imposed a no-undef in address requirement, we'd either need to replace such reasoning in AA, or have passes which wish to hoist/sink check the property afterwards. 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 speculate. %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. Philip On 9/21/20 10:41 AM, Johannes Doerfert via llvm-dev wrote:> 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 > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Maybe Matching Threads
- Is it valid to dereference a pointer that have undef bits in its offset?
- Is it valid to dereference a pointer that have undef bits in its offset?
- Is it valid to dereference a pointer that have undef bits in its offset?
- Undef and Poison round table follow-up & a plan
- Undef and Poison round table follow-up & a plan