[firrtl] Move LowerLayers after LowerXMR #8405
Draft
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.
Move the
LowerLayers
pass after theLowerXMR
pass. To do this, allpasses at the end of the CHIRRTL to Low FIRRTL pipeline are moved after
LowerXMR
. This is necessary because theLowerLayers
pass cannot, atpresent, be moved after the passes at the end of the pipeline.
This is done to enable forcing out of layers. By lowering probes to XMRs,
the layers can be lowered trivially to modules/instances and their XMRs
will now (seemingly) magically just work. By doing the loweirng in this
way, it avoids ever having to represent an input probe in the FIRRTL
dialect.
A consequence of this is that there are now simplifying
assumptions (preconditions) that can be made about the
LowerLayers
pass:It will never see a number of probe ops because the
LowerXMR
pass hasa postcondition that all of these are removed.
Input and output ports can never be created on modules created from
layer blocks.
While I am generally always in favor of passes being relocatable anywhere
in the pipeline, this is one pass that really does not make sense to be
relocatable. In effect, this pass is part of the lowering from FIRRTL to
HW. There is no point in being able to use it earlier in the pipeline.
That said, it still is tested to work with things which we may one-day
preserve, like
WhenOp
s.Todo