-
Notifications
You must be signed in to change notification settings - Fork 219
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
chore: SSA Refactor IR Review [DO NOT MERGE] #1896
Conversation
/// This map is used to ensure that the ValueId for any given foreign functôn is always | ||
/// This map is used to ensure that the ValueId for any given foreign function is always | ||
/// represented by only 1 ValueId within this function. | ||
/// TODO: can we merge this into intrinsics? | ||
foreign_functions: HashMap<String, ValueId>, |
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 must have missed this change when it was merged. I don't think we should ever key any of these maps by a String since it is unclear what it represents (a function name? Any arbitrary one, or one of a set of expected names? Are they expected to be extended later? etc).
I'd be in favor of creating a dedicated enum for foreign_functions (oracles? We use oracle elsewhere so we should be consistent in the naming), or merging them into the intrinsic enum.
@@ -68,6 +69,7 @@ pub(crate) struct DataFlowGraph { | |||
/// Debugging information about which `ValueId`s have had their underlying `Value` substituted | |||
/// for that of another. This information is purely used for printing the SSA, and has no | |||
/// material effect on the SSA itself. | |||
/// TODO: Is this true? How are we doing aliasing? |
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.
No longer true, looks like the comment has been stale for a while now. It should be updated.
@@ -103,6 +105,8 @@ impl DataFlowGraph { | |||
/// block's id. | |||
/// | |||
/// The pairs are order by id, which is not guaranteed to be meaningful. | |||
/// TODO: do we need to order by reverse post order? Is this useful? Check brillig | |||
/// TODO: ie do we need to get all successors/predecessors first? |
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 function is just for when a pass or test needs to iterate through each block and doesn't particularly care about the order (or whether the blocks are even still reachable). For passes that do care about the order, they can create a PostOrder
directly like the Dead Instruction Elimination pass does.
// TODO: Is simplify still inserting the instruction? | ||
// TODO: or are we assuming that simplify will always return a ValueId that | ||
// TODO: has already been inserted? |
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.
Simplify may potentially simplify an instruction to an existing, known value (not necessarily a constant). E.g. add x, 0
is simplified to x
. So it is expected simplify
will always return a valid ValueId if it returns SimplifyResult::SimplifiedTo
.
/// | ||
/// TODO: This is doing more than just inserting an instruction and its results |
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.
Sounds like the missing piece is that this method attempts to simplify the instruction to another value and only inserts it if it could not do so. We should:
- Update the doc comment above to note this.
- Potentially rename the function? I'm unsure what a clearer name would be.
pub(crate) fn import_intrinsic(&mut self, name: &str) -> Option<ValueId> { | ||
Intrinsic::lookup(name).map(|intrinsic| self.import_intrinsic_id(intrinsic)) | ||
} |
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.
Why are we removing this function? It looks like it makes codegen_ident
more complex.
let mut max_id = main_id; | ||
|
||
// Fetch the max_id from all functions |
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 map just maps each function id to the function it refers to, keeping track of the max_id is separate.
// TODO: why is this sorting being done here? | ||
// TODO: does the max_id need to be the main_id initially | ||
// TODO or do generally just need the max_id from all functions? | ||
let mut max_id = main_id; |
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.
There's no sorting being done here, we're just converting the Vec of functions into a btree_map so we can index the map by the function id of each function.
max_id
isn't any specific id, it's just used to keep track of what the next free id would be in case we need to add a function to this Ssa struct later and that function needs a fresh ID not shared by existing functions. That is why we initialize next_id: AtomicCounter::starting_after(max_id)
later on.
/// TODO: The above condition is somewhat hidden in the API, should we change it so that | ||
/// TODO the caller needs to pass in the main function? |
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.
Possibly, I'm not sure of a clean way to do so however. I think we'd be relying on users to manually extract main from a Vec only to have this function re-insert it afterward. The FunctionBuilder is the only real user of this function I believe so another option is to restrict the visibility a bit more.
(Note, this will never be merged) |
Closing this PR as it was not meant to be merged |
Description
Problem*
Resolves
Summary*
Documentation
This PR requires documentation updates when merged.
Additional Context
PR Checklist*
cargo fmt
on default settings.