[PATCH] D23214: [MDA] Treat invariant.start as non-dependence

Anna Thomas via llvm-commits llvm-commits at lists.llvm.org
Mon Aug 8 06:40:52 PDT 2016


Right now, with the alias analysis change marking invariant.start as readonly, we do not  value forward to invariant.end (which is still readwrite).

Also, the only use of invariant.start is the corresponding invariant.end, so I think we would be okay as long as we do not change invariant.end to be readonly. Added the test case to GVN.

define i8 @forward_store1() {
  %a = alloca i8
  store i8 0, i8* %a
  %foo = call {}* @llvm.invariant.start.p0i8(i64 1, i8* %a)
  %r = load i8, i8* %a
  %bar = call {}* @llvm.invariant.start.p0i8(i64 1, i8* %a)
  call void @llvm.invariant.end.p0i8({}* %bar, i64 1, i8* %a) <— this remains as invariant.end(%bar..)
  ret i8 %r
}

However, the value forwarding will happen when invariant.end is marked readonly as well.

foo = invariant.start(a)
<stuff>
bar = invariant.start(a)
invariant.end (foo) <— was invariant.end(bar) initially

Daniel,

Even with the value forwarding , I think the “invariant set of statements” are not modified. We are not increasing/decreasing the number of “invariant uses" of %a, even though the range of statements within invariant.start and end for foo and bar has changed. I think this is true for any other case where the value forwarding modifies invariant.end (since there would be some invariant.start which is still alive, and maintaining the invariance for uses of %a)

Thanks,
Anna

On Aug 6, 2016, at 12:30 PM, Daniel Berlin <dberlin at dberlin.org<mailto:dberlin at dberlin.org>> wrote:

So, this value forwards in a case i hadn't thought about.

foo = lifetime.start(p)
<stuff>
bar = lifetime.start(p)
lifetime.end (bar)

will become
foo = lifetime.start(p)
<stuff>
bar = lifetime.start(p)
lifetime.end (foo)


I'm not sure the above is even valid, but i found it in Real Live Code(TM).

Thoughts?



On Fri, Aug 5, 2016 at 10:15 PM, Anna Thomas <anna at azul.com<mailto:anna at azul.com>> wrote:
anna added a comment.

Changing the code to teach Alias analysis (instead of MDA) about the readonly nature of MDA. All the tests are still valid (and checks remain the same).
getModRefInfo is used by MDA, so the implications on the various passes (GVN, Memcpyopt and DSE) should be the same, it’s just that the code change will be within the same code region where other special cases for llvm.assume and guard intrinsics exist.

Making the change in alias analysis rather than MDA stemmed from the discussion in llvm-commits mailing list with dberlin and sanjoy.


https://reviews.llvm.org/D23214





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160808/cec3c7be/attachment.html>


More information about the llvm-commits mailing list