Introduce a new attribute to track qubits generated by compiler passes #3777
Conversation
Signed-off-by: Pradnya Khalate <[email protected]>
|
CUDA Quantum Docs Bot: A preview of the documentation can be found here. |
| let arguments = (ins | ||
| Optional<AnySignlessInteger>:$size | ||
| Optional<AnySignlessInteger>:$size, | ||
| UnitAttr:$compiler_generated |
There was a problem hiding this comment.
| UnitAttr:$compiler_generated | |
| OptionalAttr<UnitAttr>:$compiler_generated |
There was a problem hiding this comment.
If you add this here, you will have to add it to the syntax, add it to the roundtrip test, etc.
Note: you can add attributes to Ops without adding them formally. Every Op has an generic attribute dictionary.
Also note: this is probably of really limited use. The compiler can and will fuse quake.alloca Ops, which will almost certainly make this annotation highly suspect at best if not lost altogether.
Can you explain the actual application here? Is this to paper over the issue of throwing away named measurement registers?
There was a problem hiding this comment.
Thank you for the feedback! I was seeking direction check on this... The intention was to track compiler generated qubits and eventually filer them out.
Currently if a kernel does not use named sub-registers, the final result may have compiler generated ancilla qubits, for example, see this.
| auto alloc = builder.create<quake::AllocaOp>(loc); | ||
| alloc.setCompilerGeneratedAttr(builder.getUnitAttr()); | ||
| allocatedAncillas.push_back(alloc); |
There was a problem hiding this comment.
Yeah, if you add it formally, we'll need the whole 9 yards. Including a builder, etc.
2 participants
No description provided.