qat.core.pass_base module

class AnalysisPass

Bases: PassInfoMixin

Base class of all passes that compute some form of analysis on the input argument, with the input IR left intact.

run(ir, res_mgr, met_mgr, *args, **kwargs)
class InvokerMixin

Bases: ABC

Useful for compilation (global design-wise) stages/phases that are meant to invoke some arbitrary formation of passes in the form of a pipeline.

Organisation, registering, visibility, and discovery of pipelines w.r.t the global quantum compilation workflow is hard to pin down early on in this design partly because today’s needs are trivial and the traditional “hand-me-down” cascade-like compilation stages is likely to shift as QAT matures.

However, we’ll start by specifying that an invoker builds and runs its own pipeline, validates its analyses results, and uses those results for its purpose.

abstract build_pass_pipeline(*args, **kwargs)
Return type:

PassManager

run_pass_pipeline(arg, res_mgr, met_mgr, *args, **kwargs)
class LoweringPass

Bases: PassInfoMixin

Base case for all passes that modify the IR, instrinsically changing its type and structure.

Acts as insulation between passes that that expect to see the IR in some given format.

run(ir, res_mgr, met_mgr, *args, **kwargs)
class PassConcept

Bases: ABC

Base class describing the abstraction of a pass.

See PassManager.

abstract run(ir, res_mgr, met_mgr, *args, **kwargs)
class PassInfoMixin

Bases: ABC

Base mixin specifying pass identification mechanism. A pass has an id and name.

Such identification is loosely specified as it related closely to how passes and their results are managed throughout their lifecycle.

See PassManager.

id()
name()
class PassManager

Bases: PassInfoMixin

Contains a sequence of passes.

Represents a sequential composite of passes, which can be composites themselves. Although not explicitly specified, the pass manager is best modelled as a DAG that acts as a pass itself. In doing so, it runs a sequence of (composite or leaf) passes over the input and aggregates results from them.

Result aggregation (in general) can be achieved via return values or side effects. We adopted the latter approach where a ResultManager is passed in as argument. The rationale behind this choice is two-fold:

  1. Allow passes to peek, use, or potentially invalidate results via the ResultManager without burdening their parent PassManager.

  2. Let the passes and results define their dependency graphs on the fly which saves us from explicitly building and maintaining them. Here it’s also a possible direction to let passes lazily declare, create, and run their dependencies as they get discovered.

Result aggregation would also potentially involve cache handling as described in the ResultManager. This calls for proper pass identification, cache invalidation, and pass/result cycle detection techniques.

Example of a DAG:

(PM1 A B (PM2 C D ) E F) can be thought of as:

        <---PM2--->

           --> C
A --> B --|    ↓
           --> D --> E --> F

<-----------PM1------------>

Although the notation of a given (sub-) DAG looks sequential, passes within can run sequentially or in parallel depending on their inter-dependencies.

Notes thus far describe an ideal fully-fledged PassManager. However, today’s needs are very simple as we barely have visible features of modular quantum compilation workflow. It is therefore wise to keep the implementation light and basic where component passes run and register their own results within the ResultManager passed in as argument. Another reason is the possibility in the near future to adopt and tap into existing and mature pass pipeline infrastructure which saves us from reinventing or rediscovering the same concepts already covered by the opensource community.

add(pass_obj)

Add a pass to the pass manager.

This can be achieved by either using pass_mgr.add(pass), or pass_mgr | pass.

Parameters:

pass_obj

run(ir, res_mgr, met_mgr, *args, **kwargs)
Parameters:
class PassModel(pass_obj)

Bases: PassConcept

Implements the polymorphic pass API. A wrapper for any object providing a run() method that accepts an argument as well as a ResultManager and MetricsManager.

See PassManager.

run(ir, res_mgr, met_mgr, *args, **kwargs)
Parameters:
class TransformPass

Bases: PassInfoMixin

Base class for all passes that mutates the IR.

It is expected that child classes do not alter the type of the IR, but only alter its contents.

run(ir, res_mgr, met_mgr, *args, **kwargs)
class ValidationPass

Bases: PassInfoMixin

Base class for all passes that verify or run some form of check (i.e semantics, legalisation, …) on the IR.

Behaviour is loose as to what the result of the validation would be: either a result or an error raised. It can change according to circumstances.

run(ir, res_mgr, met_mgr, *args, **kwargs)
get_hardware_model(args, kw_args)

To be replaced with a constructor argument on the relevant passes