Skip to content

fix: migrate EPAlias to EPName where possible (#646)#1005

Open
xieofxie wants to merge 3 commits into
mainfrom
hualxie/literal_to_type
Open

fix: migrate EPAlias to EPName where possible (#646)#1005
xieofxie wants to merge 3 commits into
mainfrom
hualxie/literal_to_type

Conversation

@xieofxie

@xieofxie xieofxie commented Jun 30, 2026

Copy link
Copy Markdown
Contributor

Summary

Addresses #646 (migrate EPAlias to EPName where possible). EPNameOrAlias is the public-facing input type; EPName is the internal canonical form. This PR removes places where a bare alias was used where a canonical name belongs, and stops comparing against single alias literals.

Changes

  • analyze/utils/ep_utils.pyinfer_ihv_from_ep_name now does a direct, exact dict[EPName, IHVType] lookup covering every member of the EPName Literal. An unknown name now raises ValueError instead of silently defaulting to IHVType.MICROSOFT (the callers that matter already handle it: InformationEngine catches ValueError and falls back to loading all rules; the model validator catches it defensively). Also fixes a latent miss where CUDAExecutionProvider resolved to MICROSOFT instead of NVIDIA.
  • serve/schema.pyEpSwitchRequest.ep was the only ep field still typed bare EPAlias; every sibling is EPNameOrAlias and manager.switch_ep already accepts EPNameOrAlias. Widened it for consistency so it accepts both "qnn" and "QNNExecutionProvider".
  • compiler/utils.pyneeds_format_conversion compared ep == "qnn", a single alias literal. An EP can have multiple aliases (e.g. nv_tensorrt_rtx / nvtensorrtrtx), and the canonical name itself wouldn't match. Now normalizes via normalize_ep_name and compares against the canonical "QNNExecutionProvider"; parameter widened to EPNameOrAlias.

Notes

  • The compiler's EPConfig.provider deliberately remains alias-typed: every value it holds is an alias (provider="qnn", etc.), so retyping to EPName would require a value migration with serialization back-compat — out of scope here.
  • An audit of all ~90 EPNameOrAlias call sites confirmed every one either normalizes before a canonical sink or forwards to a callee that does — no other un-normalized canonical-sink usages were found.

Tests

  • Replaced the per-EP infer_ihv unit tests with one that verifies every EP_NAMES member resolves to an IHVType (enforcing map/Literal parity) plus an unknown-raises test.
  • Updated fixtures that relied on the old lenient behavior to use canonical EP names (ACEExecutionProviderVitisAIExecutionProvider; alias "openvino""OpenVINOExecutionProvider" in the validator tests).
  • Added test_qlinear_for_qnn_canonical_name covering the canonical-name case that previously failed in needs_format_conversion.

hualxie added 2 commits June 30, 2026 16:40
Compare against the canonical EPName instead of a single alias literal
(ep == "qnn"). An EP can have multiple aliases (e.g. nv_tensorrt_rtx /
nvtensorrtrtx) and the canonical name itself would not match, so the
alias-literal comparison was fragile. Normalize via normalize_ep_name
first and widen the parameter to EPNameOrAlias.
@xieofxie xieofxie requested a review from a team as a code owner June 30, 2026 09:09
The map covers every canonical EPName, so an unknown name now signals a
bug rather than silently defaulting to IHVType.MICROSOFT. InformationEngine
already catches ValueError (falls back to loading all rules) and the model
validator catches it defensively.

Replace the per-EP unit tests with one that verifies every EP_NAMES member
resolves to an IHVType (enforcing map/Literal parity) plus an unknown-raises
test. Update fixtures that relied on the old lenient behavior to use
canonical EP names.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant