[llvm-dev] Dereferenceable load semantics & LICM

Daniel Berlin via llvm-dev llvm-dev at lists.llvm.org
Fri Mar 31 10:33:47 PDT 2017


On Fri, Mar 31, 2017 at 10:23 AM, Sanjoy Das <sanjoy at playingwithpointers.com
> wrote:

> Hi Piotr,
>
> On March 31, 2017 at 9:07:42 AM, Piotr Padlewski
> (piotr.padlewski at gmail.com) wrote:
> > Hi all,
> > I have a question about dereferenceable metadata on load instruction. I
> > have a patch (https://reviews.llvm.org/D31539) for LICM that hoists
> loads
> > with !invariant.group.
> > The motivation example is devirtualization:
> > ...
> > [snip]
> >
> > On the other hand, after performing my LICM of !invariant.group load, GVN
> > hoists the second load and I am not sure why it is legal then.
>
> I suspect what's going on is that we first canonicalize the loop to:
>
> if (precondition) {
>   do {
>     vptr = load vtable;
>     fptr = *vptr;
>     ...
>   } while (backedge_condition);
> }
>
> after which it is safe to transform the program to (modulo aliasing):
>
> if (precondition) {
>   vptr = load vtable;
>   fptr = *vptr;
>   do {
>     ...
>   } while (backedge_condition);
> }
>
> since the we moved a load from a ("strongly") postdominating location.
> We know that once we were in the preheader we know we're definitely
> going to execute the vptr and fptr loads, so they better be
> dereferenceable.  In other words, we're "exploiting undefined
> behavior" here.
>

Yes, this appears to be exactly the case - dominance tells us they must
execute at least once in both situations.


>
> -- Sanjoy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170331/3d38117d/attachment.html>


More information about the llvm-dev mailing list