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.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
- Build Status
Buildable 35546 Build 35545: arc lint + arc unit
Event Timeline
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.
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.
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 | 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 | Why does this not also include E and F? |
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 | 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 | 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. |
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).