-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Disjoint handling in transpiler fails to rejoin barriers #11649
Comments
So the root of the issue here is a shared state issue. When There are two paths to fixing this, the first is just making a deepcopy of the dag so that there isn't a shared state when we split the barriers which will preserve the original input dag. The other option is to run |
My feeling is that running the barrier combiner with a limit to ensure it considers only the barriers split by the previous step is the cleaner approach, and the more reliable from a performance standpoint. |
This commit fixes an issue in the disjoint layout processing caused by a shared reference from the input dag to a layout pass to the internal transformations the layout processing performs. As part of the disjoint layout processing the input dag needs to be split into smaller dags for each connected component in the circuit. To enable this any barriers present in the circuit need to be split up prior to analyzing the connected components in the dag. A multiqubit barrier doesn't represent a real connectivity requirement so they need to be split prior to analysis to ensure they don't factor into the connected component computation. To faciliate not losing the semantic meaning of the barrier for the layout analysis of each connected component, the barrier split is done by first taking an n-qubit barrier and converting it into n parallel 1q barriers with a uuid label applied to it. Then after we split the circuit into the separate connected components the uuid is used to identify any components of the same barrier and combine them together. There were two issues with this approach the first is that the splitting of the barriers was done on the input dag without copying first. This causes the input dag to be modified and because in most cases it's a shared instance which would leak out the barrier splitting if the input dag was returned verbatim from the pass, which in most cases it would be. This issue is fixed by ensuring that we re-combine any split barriers after we've split the dag into it's connected components. The second issue is the uuid label assignment would overwrite any existing labels on barriers. While setting labels on barriers is uncommon for users to do (but still completely valid) this is causing a bigger issues since Qiskit#10323 because the transpiler is assigning labels to barriers it creates internally so they can be removed before the circuit is returned. This is also fixed in this commit by appending a uuid to the existing label instead of overwriting it, so we're able to restore the original label when we recombine barriers. Fixes Qiskit#11649
* Fix split barriers leaking during disjoint layout processing This commit fixes an issue in the disjoint layout processing caused by a shared reference from the input dag to a layout pass to the internal transformations the layout processing performs. As part of the disjoint layout processing the input dag needs to be split into smaller dags for each connected component in the circuit. To enable this any barriers present in the circuit need to be split up prior to analyzing the connected components in the dag. A multiqubit barrier doesn't represent a real connectivity requirement so they need to be split prior to analysis to ensure they don't factor into the connected component computation. To faciliate not losing the semantic meaning of the barrier for the layout analysis of each connected component, the barrier split is done by first taking an n-qubit barrier and converting it into n parallel 1q barriers with a uuid label applied to it. Then after we split the circuit into the separate connected components the uuid is used to identify any components of the same barrier and combine them together. There were two issues with this approach the first is that the splitting of the barriers was done on the input dag without copying first. This causes the input dag to be modified and because in most cases it's a shared instance which would leak out the barrier splitting if the input dag was returned verbatim from the pass, which in most cases it would be. This issue is fixed by ensuring that we re-combine any split barriers after we've split the dag into it's connected components. The second issue is the uuid label assignment would overwrite any existing labels on barriers. While setting labels on barriers is uncommon for users to do (but still completely valid) this is causing a bigger issues since #10323 because the transpiler is assigning labels to barriers it creates internally so they can be removed before the circuit is returned. This is also fixed in this commit by appending a uuid to the existing label instead of overwriting it, so we're able to restore the original label when we recombine barriers. Fixes #11649 * Always use string uuid * Add release note
Environment
main
@ ce02f06What is happening?
The preset passmangers for
transpile
are failing to correctly reconstruct barriers temporarily inserted during the compiler routing, which is leaking out invalidUUID
objects inside thelabel
field of those barriers.How can we reproduce the issue?
Given a set up of:
out
containsBarrier
instructions whoselabel
attributes are not strings (they'reUUID
objects) and shouldn't exist at all, because the input circuit doesn't have any:I can't draw the circuit because the visualiser will explode, as will QPY (how this issue was detected). If I coerce those particular labels just to be string instances, the circuit looks like this:
so it's clear the temporary barrier we insert before measures isn't being recombined and then deleted.
What should happen?
UUID
in theBarrier.label
field since that's supposed to be constrained to be a string (everything exceptBarrier
seems to enforce that, too).Any suggestions?
No response
The text was updated successfully, but these errors were encountered: