Page MenuHomePhabricator

Introducing llvm.invariant.group.barrier intrinsic
ClosedPublic

Authored by Prazek on Aug 24 2015, 8:20 PM.

Details

Summary
For more info for what reason it was invented, goto:
http://lists.llvm.org/pipermail/cfe-dev/2015-July/044227.html

Diff Detail

Event Timeline

Prazek updated this revision to Diff 33043.Aug 24 2015, 8:20 PM
Prazek retitled this revision from to Introducing llvm.invariant.group.barrier intrinsic & Global Opt handling.
Prazek updated this object.
Prazek added reviewers: rsmith, majnemer, nlewycky.
Prazek added a subscriber: llvm-commits.
nlewycky added inline comments.Sep 8 2015, 11:16 AM
include/llvm/IR/IRBuilder.h
1638–1639

Suggested wording: Create a call to invariant.group.barrier which stops the optimizer from propagating equality with invariant.group metadata.

lib/CodeGen/CodeGenPrepare.cpp
1414–1417

Do we also discard the !invariant.group metadata on instructions?

The backend has pointers to the Value*'s, it would be bad if they used the !invariant.group markers but all the invariant.group.barrier calls had been removed.

lib/Transforms/IPO/GlobalOpt.cpp
2507–2508 ↗(On Diff #33043)

Why is this safe? We have

%p2 = call @invariant.group.barrier(%p1)

and we set that %p2 just plain *is* %p1. Then nothing happens until evaluation completes and we commit the changes, which means replacing %p2 with %p1. At the time, why won't that operation miscompile?

I can think of two possible reasons, one is that %p1 may be constrained (like, it may be a ConstantExpr) and the other is that we may know that there are no remaining loads of either %p1 or %p2 with !invariant.group on them.

In any event, please answer in the form of a comment in this code. :)

Prazek marked an inline comment as done.Sep 8 2015, 11:28 AM
Prazek added inline comments.
lib/CodeGen/CodeGenPrepare.cpp
1414–1417

The question is, does it make any difference? What I understand, is that CodeGenPrepare is done just before machine code generation, which means that additional metadata in load/stores doesn't make any difference.

lib/Transforms/IPO/GlobalOpt.cpp
2507–2508 ↗(On Diff #33043)

What do you mean about miscompile?
I think this is safe because global-opt doesn't care about !invariant.group metadata, which means that getting rid of invariant.group.barrier will not break anything.

Prazek updated this revision to Diff 34781.Sep 14 2015, 10:26 PM
Prazek retitled this revision from Introducing llvm.invariant.group.barrier intrinsic & Global Opt handling to Introducing llvm.invariant.group.barrier intrinsic.
Prazek updated this object.

deleted globalOpt handling because it was invalid, and I want to push this one first.

Prazek added inline comments.Sep 14 2015, 11:27 PM
lib/CodeGen/CodeGenPrepare.cpp
1414–1417
nlewycky edited edge metadata.Sep 15 2015, 8:41 AM

Is there a LangRef change that introduces the barrier? If that's simply in a different review, then LGTM. Usually I'd ask for the feature and the LangRef change to land together, but it also makes sense to put the LangRef update for !invariant.group and @llvm.invariant.group.barrier together.

rsmith accepted this revision.Sep 15 2015, 10:33 AM
rsmith edited edge metadata.

The LangRef updates are in http://reviews.llvm.org/D11399; approving based on Nick's conditional LGTM.

This revision is now accepted and ready to land.Sep 15 2015, 10:33 AM
Prazek closed this revision.Sep 15 2015, 11:34 AM