-
Notifications
You must be signed in to change notification settings - Fork 13.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[feedback] per-edge dataflow #47664
[feedback] per-edge dataflow #47664
Changes from 2 commits
68b9f0b
3f768fd
af62153
3056861
7619704
0285472
5fe40f6
642815f
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -612,11 +612,10 @@ pub trait BitDenotation: BitwiseOperator { | |
/// `sets.on_entry` to that local clone into `statement_effect` and | ||
/// `terminator_effect`). | ||
/// | ||
/// When its false, no local clone is constucted; instead a | ||
/// reference directly into `on_entry` is passed along via | ||
/// `sets.on_entry` instead, which represents the flow state at | ||
/// the block's start, not necessarily the state immediately prior | ||
/// to the statement/terminator under analysis. | ||
/// When its false, no local clone is constucted; instead it is | ||
/// undefined what `on_entry` points to (in practice, it will | ||
/// frequently be a reference the flow state at the block's start, | ||
/// but you should not rely on that). | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think this is a good change (in that no one should be or have been using the stronger guarantee in the earlier version of the comment). But I am curious: Did you actually concoct some scenario that invalidated the comment's stronger claim? Or are you figuring that we're better off not defining the semantics in this case? |
||
/// | ||
/// In either case, the passed reference is mutable; but this is a | ||
/// wart from using the `BlockSets` type in the API; the intention | ||
|
@@ -674,7 +673,7 @@ pub trait BitDenotation: BitwiseOperator { | |
/// `bb_data` is the sequence of statements identified by `bb` in | ||
/// the MIR. | ||
fn statement_effect(&self, | ||
sets: &mut BlockSets<Self::Idx>, | ||
sets: &mut BlockSets<'_, Self::Idx>, | ||
location: Location); | ||
|
||
/// Similar to `terminator_effect`, except it applies | ||
|
@@ -703,7 +702,7 @@ pub trait BitDenotation: BitwiseOperator { | |
/// The effects applied here cannot depend on which branch the | ||
/// terminator took. | ||
fn terminator_effect(&self, | ||
sets: &mut BlockSets<Self::Idx>, | ||
sets: &mut BlockSets<'_, Self::Idx>, | ||
location: Location); | ||
|
||
/// Mutates the block-sets according to the (flow-dependent) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This comment may be made irrelevant by later commits in the series, but I don't think it was correct to replace
IdxSet
withBlockSets
here.IIRC,
BlockSets
is a triple of sets associated with the block currently being processed. Butfn propagate_call_return
needs to modify the successor block for the call terminator, which is why we pass in the wholein_out
here and not just the three sets for the current block.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(I think a commit further down the line did indeed make this feedback irrelevant. If it was ever relevant in the first place, which I am no longer certain of; the
IdxSet
here is not for the whole universe of blocks anyway...)