compile_decomposition_rules recompiles identical operator variants many times under capture

Summary

Under qml.qjit(capture=True) graph decomposition, the compiler's on-demand rule loader rebuilds the full reachable-rule closure for every operator it asks about, which recompiles the same operator variant many times over. Compiling a single variant is cheap (~tens of ms), but the closure explosion makes compile_decomposition_rules the dominant cost of decomposition-heavy programs.

compile_decomposition_rules (frontend/catalyst/decomposition/decomposition_rules.py) is a pure function of its arguments (operator name + resolved instance id, dynamic shape, wire lengths, static/extra data, and the adjoint/control modifier variant), yet its result is never cached.

Observed

On the RZ phase-gradient decomposition demo (Clifford+T target gate set), compile_decomposition_rules was invoked ~5870 times for only ~179 unique (operator variant) keys, i.e. the vast majority of calls recompute an already-compiled module. This rule-compilation phase dominates end-to-end compile time for such programs.

Proposed improvement

Memoize compile_decomposition_rules keyed by the fully-resolved operator instance and modifier variant. The returned inlined_module is only walked/cloned downstream (never mutated), so sharing the same module across callers is safe.

Environment

• catalyst 0.16.0-dev86 (main)
• pennylane 0.46.0-dev88
• jax 0.7.1

Start in frontend/catalyst/decomposition/decomposition_rules.py by reading compile_decomposition_rules and its call sites, then inspect how the fully resolved operator instance and modifier variant are represented. Add memoization without changing downstream module handling, and verify that repeated identical variants compile once while decomposition results remain unchanged; use the RZ phase-gradient decomposition demo to assess the performance improvement.