ETRecord: capture delegate _delegate_info_meta into ETRecord#21379
ETRecord: capture delegate _delegate_info_meta into ETRecord#21379Gasoonjia wants to merge 1 commit into
_delegate_info_meta into ETRecord#21379Conversation
Summary:
Backends can attach arbitrary per-delegate info during lowering via
`PreprocessResult._delegate_info_meta`, which `to_backend` copies onto
`lowered_module.meta["_delegate_info_meta"]`. Until now that info dead-ended on
the lowered module and never reached the ETRecord. This diff carries it the last
mile so it can be inspected after an ETRecord is parsed back.
What changed:
- `ETRecord` gains a `delegate_info: Dict[str, Any]` field, stored as a single
JSON blob (reserved name `delegate_info`), keyed by `f"{method}/{lowered_name}"`.
- Extraction lives entirely inside ETRecord (no delegate-specific logic in
`_program.py`). `_maybe_extract_delegate_info` is called from
`add_edge_dialect_program` and `add_executorch_program`, gated so it runs only
when (a) the ETRecord has no delegate_info yet and (b) the incoming graph
actually carries it. All recorded graphs are the same model, so it is captured
exactly once. It walks lowered submodules (recursing into control-flow
submodules) and skips non-JSON-serializable values (with a warning) so a
backend cannot break ETRecord saving.
- Covers both flows: `to_edge_transform_and_lower(...)` (captured at
`add_edge_dialect_program`) and `to_edge(...).to_backend(...)` (captured at
`add_executorch_program`, since the delegated graph is only available there).
- Example backend now logs a minimal, non-static fingerprint
(`sha256(processed_bytes)`) via `_delegate_info_meta` as the reference pattern
for other backends (Arm/XNNPACK) to follow.
Note: `exir/program/_program.py` is intentionally untouched.
Differential Revision: D113189648
🔗 Helpful Links🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/21379
Note: Links to docs will display an error until the docs builds have been completed. ❌ 4 New Failures, 41 Unrelated FailuresAs of commit 210a94d with merge base e2c9a48 ( NEW FAILURES - The following jobs have failed:
FLAKY - The following jobs failed but were likely due to flakiness present on trunk:
BROKEN TRUNK - The following jobs failed but were present on the merge base:👉 Rebase onto the `viable/strict` branch to avoid these failures
This comment was automatically generated by Dr. CI and updates every 15 minutes. |
|
@Gasoonjia has exported this pull request. If you are a Meta employee, you can view the originating Diff in D113189648. |
This PR needs a
|
Summary:
Backends can attach arbitrary per-delegate info during lowering via
PreprocessResult._delegate_info_meta, whichto_backendcopies ontolowered_module.meta["_delegate_info_meta"]. Until now that info dead-ended onthe lowered module and never reached the ETRecord. This diff carries it the last
mile so it can be inspected after an ETRecord is parsed back.
What changed:
ETRecordgains adelegate_info: Dict[str, Any]field, stored as a singleJSON blob (reserved name
delegate_info), keyed byf"{method}/{lowered_name}"._program.py)._maybe_extract_delegate_infois called fromadd_edge_dialect_programandadd_executorch_program, gated so it runs onlywhen (a) the ETRecord has no delegate_info yet and (b) the incoming graph
actually carries it. All recorded graphs are the same model, so it is captured
exactly once. It walks lowered submodules (recursing into control-flow
submodules) and skips non-JSON-serializable values (with a warning) so a
backend cannot break ETRecord saving.
to_edge_transform_and_lower(...)(captured atadd_edge_dialect_program) andto_edge(...).to_backend(...)(captured atadd_executorch_program, since the delegated graph is only available there).(
sha256(processed_bytes)) via_delegate_info_metaas the reference patternfor other backends (Arm/XNNPACK) to follow.
Note:
exir/program/_program.pyis intentionally untouched.Differential Revision: D113189648