Ensure we run VF2PostLayout when needed in optimization level 1 #9941
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
mtreinish
added
priority: high
Changelog: New Feature
|
Thank you for opening a new pull request. Before your PR can be merged it will first need to pass continuous integration tests and be reviewed. Sometimes the review process can be slow, so please be patient. While you're waiting, please feel free to review other open PRs. While only a subset of people are authorized to approve pull requests for merging, everyone is encouraged to review open pull requests. Doing reviews helps reduce the burden on the core team and helps make the project's code better for everyone. One or more of the the following people are requested to review this:
|
Pull Request Test Coverage Report for Build 4670573548
💛 - Coveralls |
This commit fixes an issue where we were incorrectly not running VF2PostLayout in the one case where it should be run. Optimization level 1 is more involved than higher optimization levels because for backwards compatibility it runs multiple different passes to try and find a perfect layout, first starting with TrivialLayout, then VF2Layout, and only if those 2 fail to find a perfect match do we run SabreLayout (or DenseLayout and StochasticSwap if control flow are present). We only should run VF2PostLayout if we're running the heuristic layout pass. However, when we integrated routing into SabreLayout the checking for whether we found a pefect layout in the layout stage stopped working as expected. To fix this issue a new flag is added to the CheckMap pass to specify an alternative property set field to store the results of the check in. The underlying issue was that the property set field between the earlier check that we found a perfect layout and the later check whether we should run a standalone routing pass. To fix this the new flag is used to spearate the results from the multiple CheckMap calls. and then we only condition the VF2PostLayout condition on the results of the perfect layout check and not the later routing check. Fixes Qiskit#9936
mtreinish
force-pushed
the
add-property_set_option-check-map
branch
from
429d4b0
to
6071f05
Compare
jakelishman
reviewed
Apr 11, 2023
|
Sigh, that's what I get for copy and pasting tests while I was in meetings. Let me remove those inaccurate comments. |
jakelishman
approved these changes
Apr 11, 2023
giacomoRanieri
pushed a commit
to giacomoRanieri/qiskit-terra
that referenced
this pull request
Apr 16, 2023
…it#9941) * Ensure we run VF2PostLayout when needed in optimization level 1 This commit fixes an issue where we were incorrectly not running VF2PostLayout in the one case where it should be run. Optimization level 1 is more involved than higher optimization levels because for backwards compatibility it runs multiple different passes to try and find a perfect layout, first starting with TrivialLayout, then VF2Layout, and only if those 2 fail to find a perfect match do we run SabreLayout (or DenseLayout and StochasticSwap if control flow are present). We only should run VF2PostLayout if we're running the heuristic layout pass. However, when we integrated routing into SabreLayout the checking for whether we found a pefect layout in the layout stage stopped working as expected. To fix this issue a new flag is added to the CheckMap pass to specify an alternative property set field to store the results of the check in. The underlying issue was that the property set field between the earlier check that we found a perfect layout and the later check whether we should run a standalone routing pass. To fix this the new flag is used to spearate the results from the multiple CheckMap calls. and then we only condition the VF2PostLayout condition on the results of the perfect layout check and not the later routing check. Fixes Qiskit#9936 * Fix remove out of date comments
king-p3nguin
pushed a commit
to king-p3nguin/qiskit-terra
that referenced
this pull request
May 22, 2023
…it#9941) * Ensure we run VF2PostLayout when needed in optimization level 1 This commit fixes an issue where we were incorrectly not running VF2PostLayout in the one case where it should be run. Optimization level 1 is more involved than higher optimization levels because for backwards compatibility it runs multiple different passes to try and find a perfect layout, first starting with TrivialLayout, then VF2Layout, and only if those 2 fail to find a perfect match do we run SabreLayout (or DenseLayout and StochasticSwap if control flow are present). We only should run VF2PostLayout if we're running the heuristic layout pass. However, when we integrated routing into SabreLayout the checking for whether we found a pefect layout in the layout stage stopped working as expected. To fix this issue a new flag is added to the CheckMap pass to specify an alternative property set field to store the results of the check in. The underlying issue was that the property set field between the earlier check that we found a perfect layout and the later check whether we should run a standalone routing pass. To fix this the new flag is used to spearate the results from the multiple CheckMap calls. and then we only condition the VF2PostLayout condition on the results of the perfect layout check and not the later routing check. Fixes Qiskit#9936 * Fix remove out of date comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Summary
This commit fixes an issue where we were incorrectly not running
VF2PostLayout in the one case where it should be run. Optimization level
1 is more involved than higher optimization levels because for backwards
compatibility it runs multiple different passes to try and find a
perfect layout, first starting with TrivialLayout, then VF2Layout, and
only if those 2 fail to find a perfect match do we run SabreLayout (or
DenseLayout and StochasticSwap if control flow are present). We only
should run VF2PostLayout if we're running the heuristic layout pass.
However, when we integrated routing into SabreLayout the checking for
whether we found a pefect layout in the layout stage stopped working as
expected.
To fix this issue a new flag is added to the CheckMap pass to specify an
alternative property set field to store the results of the check in. The
underlying issue was that the property set field between the earlier
check that we found a perfect layout and the later check whether we
should run a standalone routing pass. To fix this the new flag is used
to separate the results from the multiple CheckMap calls. and then we
only condition the VF2PostLayout condition on the results of the perfect
layout check and not the later routing check.
Details and comments
Fixes #9936