This is an archive of the discontinued LLVM Phabricator instance.

[MustExec] Add a generic "must-be-executed-context" explorer
ClosedPublic

Authored by jdoerfert on Jul 23 2019, 8:16 PM.

Details

Summary

Given an instruction I, the MustBeExecutedContextExplorer allows to
easily traverse instructions that are guaranteed to be executed whenever
I is. For now, these instruction have to be statically "after" I, in
the same or different basic blocks.

Diff Detail

Repository
rL LLVM

Event Timeline

jdoerfert created this revision.Jul 23 2019, 8:16 PM
jdoerfert updated this revision to Diff 211408.Jul 23 2019, 9:03 PM

Use in ArgumentPromoton (fixed bug), add test, remove unused methods

nikic added a subscriber: nikic.Jul 29 2019, 2:12 PM

I'm not sure I understand the design/purpose of this utility. As far as I can see, the main benefit this has over a standard guaranteed-to-transfer loop is that it will be able to continue into a unique successor BB. As most must-exec uses I've seen (including your ArgPromotion example, as well as attribute deduction uses) are interested in instructions that must-exec from entry, this will not happen for non-degenerate CFGs (where BBs have not been merged).

To get something more accurate than a guaranteed-to-transfer loop over the entry block for purposes like attribute deduction, a different interface would be needed that can handle multiple successor blocks. Basically a backwards propagation that discards facts if there's no guaranteed-transfer.

jdoerfert added a comment.EditedJul 29 2019, 10:53 PM

Thanks for taking a look at this!

You are right, this is not what we actually want to do. What we want to do is shown in D64975, basically the final version of this which I haven't mentioned here before.
In a nutshell, the final version can find join points in the CFG (forward/backward direction), enter functions in the CallGraph (forward/backward direction), and use analyses to improve the result.
This commit introduces most of the boilerplate, the interface so we can start implementing users, and a testable subset of the rather large logic part.

I'm not sure I understand the design/purpose of this utility. As far as I can see, the main benefit this has over a standard guaranteed-to-transfer loop is that it will be able to continue into a unique successor BB. As most must-exec uses I've seen (including your ArgPromotion example, as well as attribute deduction uses) are interested in instructions that must-exec from entry, this will not happen for non-degenerate CFGs (where BBs have not been merged).

While beyond the point, the statement is not true. Take the loop header (=the loop body of "do-style" loops) as an example where the unique successor block is not mergeable with the predecessor.
(Basically anytime control merges in the unique successor we cannot merge.)

To get something more accurate than a guaranteed-to-transfer loop over the entry block for purposes like attribute deduction, a different interface would be needed that can handle multiple successor blocks. Basically a backwards propagation that discards facts if there's no guaranteed-transfer.

Site note: We do not only want to do entry block exploration but that is also beyond the point here (see D65402, turns out that patch only looks at entry blocks as a starting point but we should look at call sites as starting point as well).

I think that this looks fine, but it should have some direct tests. Either make an analysis that prints out things and then some lit tests, or, some unit tests.

llvm/include/llvm/Analysis/MustExecute.h
232 ↗(On Diff #211408)

This comment, that all instructions A-E will be visited, seems contradicted by the table below (where starting at A visits {A, B} and starting at B visits {B} and so on).

250 ↗(On Diff #211408)

Why does this not also include E and F?

jdoerfert marked 2 inline comments as done.

Add printer and explicit tests, fix examples in the comment

Reverted the comments/examples in the comments back to their original form. Added the second more complex one.
The comment states that this might not be what you get (as it isn't now) but they explain the idea rather nicely.

I also added a printer pass and the tests from the example so we can "see" the progress.

llvm/include/llvm/Analysis/MustExecute.h
232 ↗(On Diff #211408)

That was me changing the comment from the original to the less powerful striped down version even if that was actually not necessary. Will make it consistent again (see below).

250 ↗(On Diff #211408)

In this patch it wouldn't derive this, though, maybe I should make the comment include them again (the original comment, and others I removed did contain E and F.

hfinkel accepted this revision.Aug 21 2019, 6:29 AM

LGTM

This revision is now accepted and ready to land.Aug 21 2019, 6:29 AM
This revision was automatically updated to reflect the committed changes.
jdoerfert marked 2 inline comments as done.