Backend¶
Per-architecture behaviour, kept out of the passes.
Passes never branch on BackendType. Everything architecture-specific — codegen
target, runtime API names, hazard workarounds, cross-core layout rules — is answered
by a BackendHandler obtained from the active PassContext. Adding an architecture
means adding a handler, not editing passes.
| Page | What it covers |
|---|---|
| BackendHandler: principled backend dispatch | The virtual interface, how passes query it, and what adding a new backend requires |
| Synchronization hardware resources | Resource domain queries, ID ranges, and compiler reservation policy |
| ISA macro synchronization resources | Backend-owned ISA signal occupancy declarations and queries |
Registered operator inventory¶
Query a concrete backend to enumerate its actual operator registrations:
from pypto import backend
target = backend.get_backend_instance(backend.BackendType.Ascend910)
names = target.get_registered_op_names()
The returned list is sorted and independent of the registry. It includes the
target's exclusions and overrides, without changing the global backend selection.
Use this inventory when auditing lowering coverage; parsing registration source
can count commented examples or miss names registered through shared tables.
Registration alone does not guarantee support for every dtype, shape, or layout.
The list also includes legacy backend entries whose IR operators no longer exist;
use ir.is_op_registered(name) to distinguish those when auditing current IR.
The audit ledger lives in tests/ut/backend/buffer_migration_inventory.py:
MIGRATION_FAMILIES classifies 168 live names in 22 families, and
HISTORICAL_CALLBACKS records eight historical callbacks. Update this module
whenever the registered surface changes. Its validator,
tests/ut/backend/test_buffer_migration_inventory.py, compares the ledger with
both runtime registries. It detects new or deleted names, duplicate
classifications, target changes, and historical callbacks that acquire an IR
definition.
The ledger's PLANNED and RESTRICTED statuses describe declared migration
maturity. RESTRICTED means some forms are implemented; it does not promise
support for every dtype, layout, attribute, or target form. This guard makes
inventory omissions fail tests. Production conversion recipes and their
conversion, native compilation, and numerical tests establish implementation
coverage; the audit ledger does not drive lowering or enable the default switch.
The guard also queries backend.get_buffer_elementwise_recipe_names(), the
actual table used by logical conversion and native emission. Every reported
recipe must have a live backend operation and a RESTRICTED audit classification.
This keeps maturity declarations current without duplicating production
instruction mappings or claiming complete form coverage.
See Also¶
- Pass, PassContext, PassPipeline, and PassManager — where the handler comes from.
- PTO ISA reference — the hardware differences the handlers abstract over.
Backend names¶
Use BackendType.Ascend910 for the A2/A3 backend and BackendType.Ascend950
for A5. BackendType.Ascend910B remains a compatibility alias of
BackendType.Ascend910 in both Python and C++; both names select the same target.
The canonical .name and newly written artifact metadata use Ascend910.
Existing artifacts containing Ascend910B remain readable; older PyPTO releases
may not recognize new artifacts containing Ascend910. Platform strings
(a2a3, a2a3sim, a5, a5sim) and enum integer values are unchanged.