Fix handling of multiple assignments in inlining #60
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This fixes a case where multiple assignments to a variable were not being treated properly in the nested blacklisting logic. Here's an example where this code:
would turn into
Notice
coreir_commonlib_mux2x6_inst0_in_data_1
isn't inlined, this is because it drivescoreir_commonlib_mux2x6_inst0_out_unq1
which in turn drives a slice that shouldn't be inlined, so the recursive inline logic prevents it from being inlined.However, it should see that
coreir_commonlib_mux2x6_inst0_out_unq1
is assigned twice, so it won't be inlined, which then allowscoreir_commonlib_mux2x6_inst0_in_data_1
.This change moves the assignment count logic up to the front to blacklist wires from being inlined if they're assigned more than once, than updates the recursive blacklisting logic to detect and stop when it encounters a wire that's already being blacklisted (which then allows other drivers to be inlined, rather than continuing to recurse).
Also adds a convenience construct to If when there are no else_ifs