Page MenuHomePhabricator

Introducing intrinsic

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


For more info for what reason it was invented, goto:

Diff Detail

Event Timeline

Prazek updated this revision to Diff 33043.Aug 24 2015, 8:20 PM
Prazek retitled this revision from to Introducing 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

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


Do we also discard the ! metadata on instructions?

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

2507–2508 ↗(On Diff #33043)

Why is this safe? We have

%p2 = call

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 ! 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.

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.

2507–2508 ↗(On Diff #33043)

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

Prazek updated this revision to Diff 34781.Sep 14 2015, 10:26 PM
Prazek retitled this revision from Introducing intrinsic & Global Opt handling to Introducing 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
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 ! and together.

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

The LangRef updates are in; 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