[PATCH] D29064: [MemorySSA] Add invariant.group handling

[Piotr Padlewski via Phabricator via llvm-commits]

Prazek added a comment.

In https://reviews.llvm.org/D29064#654327, @george.burgess.iv wrote:

> Thanks for this!
>
> Haven't looked over the patch in great detail, but I do have a few high-level questions:
>
> - Is it possible for an invariant group barrier to ever be removed from/added to a function? If so, then we're either going to have to treat it as Def, or we're going to have to add a `byTheWayThisInvariantBarrierIsNowDead` and/or a `weHaveANewInvariantBarrier` function to MemorySSA.


Yes, it is sometimes possible to remove barrier. Case like

  %unused = i8* @llvm.invariant.group.barrier(%x)

So when the result is unused. I think this could be achieved by giving some attributes to barrier like readonly, so that optimizer will
know that this can be removed if return value is unused. I haven't looked into that in the detail, but I am sure there is, or could
exist attribute that does this.

Other case is when barrier has only
one use, which is barrier, then we could remove it

  %b = @llvm.invariant.group.barrier(%p)
  %b2 = @llvm.invariant.group.barrier(%b)

In this case %b could be removed.

Hovewer I am thinking about some other method. I would like to have all the optimizations
working the same as if I would remove all the barriers and invariant groups, but without removing them.
One of the case is

  store 42, %p
  %a = @llvm.invariant.group.barrier(%p)
  load %a

In this case the load will have the correct MemoryUse, but the optimizer won't be able to figure out the value of load
or the case like

  store 42, %x
  %a = @llvm.invariant.group.barrier(%x)
  store 41, %a

In this case first store is dead.
So I don't yet know how to handle these cases, but I will at DSE and newGVN to figure it out.

> - Is it possible to add/remove/move an operation with invariant group metadata on it? If so, we'll probably need to change the update API to handle those cases sanely (otherwise, looks like PerBlockInvariantGroupAccesses can end up with dangling pointers?)

Yes, PerBlockInvariantGroupAccess will have dangling pointers, but I was planning to only use it in OptimizeUses, which is used only ones where we still have all the instructions. Hovewer this might change because I have to take a look at the walker as Daniel said.


https://reviews.llvm.org/D29064