[PATCH] D31539: Hoisting invariant.group in LICM
Piotr Padlewski via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Mon Apr 3 02:34:48 PDT 2017
Prazek added a comment.
In https://reviews.llvm.org/D31539#716384, @sanjoy wrote:
> > It would, but that would mean that either the !invariant.group metadata is invalid there, or the store is storing the same value as it is loaded (so it would probably have !invariant.group
> > there, but it doesn't matter).
> > If I would unroll this loop:
> >
> > vtable.pre = load ptr0, !invariant.group
> > use(vtable.pre)
> > store new vtable to ptr0
> > ptr1 = barrier(ptr0)
> > for (;;) {
> > vtable = load ptr0, !invariant.group
> > use(vtable)
>
> Does this reasoning still hold if the loop has just one iteration? That is, say the loop was
>
> for (i = 0; i < 1; i++) {
> vtable = load ptr0, !invariant.group
> use(vtable)
> store new vtable to ptr0 // S0
> ptr1 = barrier(ptr0)
> // ptr1 is not used, say
> }
>
>
> then (I claim that) the program does not have UB even if `S0` is storing a new vtable. I think this is the kind of IR we'll get from
>
> for (i = 0; i < 1; i++) {
> storage->f();
> storage->~Foo();
> new(storage) Bar;
> }
>
>
>
>
> > Or maybe you are refering to the fact that invariant.group metadata would be preserved? If this is a case, then see my post on mailing list :)
>
> I thought your mailing list post was about //speculating// loads. Here we're not speculating anything -- we're only sinking. In any case, you do not need the `!invariant.group` metadata on the sunk load for the example above to "work".
So it looks like we can't sink based on invariant.group, but I guess hoisting is still possible, because
it would be only invalid if there would be a store before the load
for (i = 0; i < 1; i++) {
store new vtable to ptr0 // S0
vtable = load ptr0, !invariant.group
use(vtable)
}
but then if store stores different value, that means it is UB. Is this right?
https://reviews.llvm.org/D31539
More information about the llvm-commits
mailing list