🐛 Invalid / Duplicated Metadata Produced By QIR Builder / Translation

[MatthiasReumann]

Description

The QIR translation / clean-up pass doesn't correctly update / set the function meta-data.

Example 1

When building a program using the QIRProgramBuilder and running runQIRCleanupPipeline afterwards, the required_num_qubits and required_num_results attributes are invalid.

QIRProgramBuilder builder(context.get());
builder.initialize();
builder.staticQubit(0);
builder.staticQubit(1);

auto program = builder.finalize();
program->dump();
runQIRCleanupPipeline(program.get());
program->dump();

Dump 1

Duplicated, but correct: There are two qubits "used" in this computation.

module {
  llvm.func @main() -> i64 attributes {passthrough = ["entry_point", ["output_labeling_schema", "labeled"], 
["qir_profiles", "base_profile"], ["required_num_qubits", "2"], 
["required_num_results", "0"], ["required_num_qubits", "2"], 
["required_num_results", "0"], ["qir_major_version", "2"], ["qir_minor_version", "1"]]} {
    %0 = llvm.mlir.constant(0 : i64) : i64
    %1 = llvm.mlir.zero : !llvm.ptr
    llvm.call @__quantum__rt__initialize(%1) : (!llvm.ptr) -> ()
    llvm.br ^bb1
  ^bb1:  // pred: ^bb0
    %2 = llvm.mlir.constant(0 : i64) : i64
    %3 = llvm.inttoptr %2 : i64 to !llvm.ptr
    %4 = llvm.mlir.constant(1 : i64) : i64
    %5 = llvm.inttoptr %4 : i64 to !llvm.ptr
    llvm.br ^bb2
  ^bb2:  // pred: ^bb1
    llvm.br ^bb3
  ^bb3:  // pred: ^bb2
    llvm.return %0 : i64
  }
  llvm.func @__quantum__rt__initialize(!llvm.ptr)
}

Dump 2

Duplicated and incorrect: The computation doesn't use any qubits.

module {
  llvm.func @main() -> i64 attributes {passthrough = ["entry_point", ["output_labeling_schema", "labeled"], ["qir_profiles", "base_profile"], ["required_num_qubits", "2"], ["required_num_results", "0"], ["required_num_qubits", "2"], ["required_num_results", "0"], ["qir_major_version", "2"], ["qir_minor_version", "1"]]} {
    %0 = llvm.mlir.constant(0 : i64) : i64
    %1 = llvm.mlir.zero : !llvm.ptr
    llvm.call @__quantum__rt__initialize(%1) : (!llvm.ptr) -> ()
    llvm.br ^bb1
  ^bb1:  // pred: ^bb0
    llvm.br ^bb2
  ^bb2:  // pred: ^bb1
    llvm.br ^bb3
  ^bb3:  // pred: ^bb2
    llvm.return %0 : i64
  }
  llvm.func @__quantum__rt__initialize(!llvm.ptr)
}

Example 2

When compiling the following program to QIR (mqt-cc ~/Documents/program.qasm), the required_num_qubits and required_num_results attributes set by the translation are duplicated.

module {
    func.func @main() -> i64 attributes {passthrough = ["entry_point"]} {
        qc.static 0 : !qc.qubit 
        qc.static 1 : !qc.qubit
        
        %c0 = arith.constant 0 : i64
        return %c0 : i64
    }
}

module {
  llvm.func @main() -> i64 attributes {passthrough = ["entry_point", ["output_labeling_schema", "labeled"], ["qir_profiles", "base_profile"], 
["required_num_qubits", "0"], ["required_num_results", "0"], 
["required_num_qubits", "0"], ["required_num_results", "0"], // ← duplicated entry.
["qir_major_version", "2"], ["qir_minor_version", "1"]]} {
    %0 = llvm.mlir.constant(0 : i64) : i64
    %1 = llvm.mlir.zero : !llvm.ptr
    llvm.call @__quantum__rt__initialize(%1) : (!llvm.ptr) -> ()
    llvm.br ^bb1
  ^bb1:  // pred: ^bb0
    llvm.br ^bb2
  ^bb2:  // pred: ^bb1
    llvm.br ^bb3
  ^bb3:  // pred: ^bb2
    llvm.return %0 : i64
  }
  llvm.func @__quantum__rt__initialize(!llvm.ptr)
}

Expected Outcome

module {
  llvm.func @main() -> i64 attributes {passthrough = ["entry_point", ["output_labeling_schema", "labeled"], ["qir_profiles", "base_profile"], 
["required_num_qubits", "0"], ["required_num_results", "0"], // ← No Duplicated entry.
["qir_major_version", "2"], ["qir_minor_version", "1"]]} {
    %0 = llvm.mlir.constant(0 : i64) : i64
    %1 = llvm.mlir.zero : !llvm.ptr
    llvm.call @__quantum__rt__initialize(%1) : (!llvm.ptr) -> ()
    llvm.br ^bb1
  ^bb1:  // pred: ^bb0
    llvm.br ^bb2
  ^bb2:  // pred: ^bb1
    llvm.br ^bb3
  ^bb3:  // pred: ^bb2
    llvm.return %0 : i64
  }
  llvm.func @__quantum__rt__initialize(!llvm.ptr)
}

[burgholzer]

Huh.. that's strange 🙃
I would even argue these are two separate issues:

• Duplication of the metadata. This should only be added once. Should be fairly easy to identify the place where this gets added twice
• Updates of the metadata after cleanup/canonicalization. This is a bit trickier potentially. But maybe also not. The removal of an allocation of a qubit has to also update the number of qubits supposedly. And the same probably goes for measurements and classical results.

Sounds like two fairly contained fixes.
@MatthiasReumann do you plan to take these on?

[MatthiasReumann]

I would even argue these are two separate issues

Yes, definitely!

@MatthiasReumann do you plan to take these on?

I will tackle these once I'm somewhat happy with the current verifier implementation, yes.

Nonetheless, if someone else wants to work on it in the meantime, feel free to! Otherwise, I will post a comment here when I start working on the issue.

[denialhaag]

It might be worth checking whether #1710 inadvertently fixes this already. 🤔

[li-mingbao]

Hey,
The first issue with duplicate attributes should be fixed in the updated conversions in #1710.

The second issue still exists. The problem is that when you only create static qubits without using them, ìnttoptr operations are created and getting removed during via a standard dead code removal as this operation does not produce any side-effects. So I am not sure what the best way is to update the number of qubits/results. Afaik there is no way to check which operations are getting removed during a default pass, right? During the conversion this should not happen as the dead operations are getting removed earlier before the conversion to QIR, so the error only happens in the QIRBuilder.

Btw, from what I have seen the current Module checker also does not check if the attributes of the main functions are the same. Maybe thats something for updated IR verification @MatthiasReumann.

[burgholzer]

Hey, The first issue with duplicate attributes should be fixed in the updated conversions in #1710.

Nice!

The second issue still exists. The problem is that when you only create static qubits without using them, ìnttoptr operations are created and getting removed during via a standard dead code removal as this operation does not produce any side-effects. So I am not sure what the best way is to update the number of qubits/results. Afaik there is no way to check which operations are getting removed during a default pass, right? During the conversion this should not happen as the dead operations are getting removed earlier before the conversion to QIR, so the error only happens in the QIRBuilder.

I think we may want to introduce a cleanup pass that runs after the canonicalization on the QIR program and re-checks+updates the QIR metadata and attributes. I see no real way around that, but this should also moderately easy to add.

Btw, from what I have seen the current Module checker also does not check if the attributes of the main functions are the same. Maybe thats something for updated IR verification @MatthiasReumann.

I think I removed this in the initial implementation because it led to some problems. I don't fully remember, but either it was exactly this issue and I did not notice or it had to do with the ordering of the attributes that made the verifier more complex.

[MatthiasReumann]

I think I removed this in the initial implementation because it led to some problems. I don't fully remember, but either it was exactly this issue and I did not notice or it had to do with the ordering of the attributes that made the verifier more complex.

Yeah. There is some weird behavior going on with attributes in one of our conversions or canonicalization patterns. I tried to pinpoint it but after two hours of searching I gave up.

The problem is when creating a memref::LoadOp the nontemporal attribute is set to false per default. Now, somewhere this attribute goes missing and I have absolutely no idea where. However, as far as I can tell we create the LoadOps always using the respective builder (which sets the nontemporal attribute)¹.

Consequently, matching attributes 1:1 is really hard.

Footnotes

1. assert(newLoad.hasAttr("nontemporal")) doesn't fail either. ↩

[burgholzer]

I think this is a fairly similar conclusion to the one I arrived at when initially implementing the verifier.
I hate to say it, but maybe some lit/FileCheck tests would go a long way here.
@denialhaag we already talked about it at some point.

[MatthiasReumann]

The second issue still exists. The problem is that when you only create static qubits without using them, ìnttoptr operations are created and getting removed during via a standard dead code removal as this operation does not produce any side-effects. So I am not sure what the best way is to update the number of qubits/results. Afaik there is no way to check which operations are getting removed during a default pass, right? During the conversion this should not happen as the dead operations are getting removed earlier before the conversion to QIR, so the error only happens in the QIRBuilder.

I guess there two options:

• Do not run any additional passes after toQIR. This assume that the DCE has already removes unused qubits and the toQIR is the final step in the compilation pipeline, which it kind of already is as a translation from MLIR to (semi-)LLVM.
• Do not set the meta data in the toQIR pass, but rather run a set-qir-metadata pass after the canonicalization passes.