[RFC] Expanding ONNX operator coverage in the Relax frontend #20124

Context

The Relax ONNX frontend currently implements ~160 operators from the ONNX spec. Comparing against the current operator list (https://onnx.ai/onnx/operators/index.html), a number of ops are not yet supported.

Before opening PRs, I'd like to check on priorities/approach with maintainers. I went through python/tvm/relax/op/ and python/tvm/topi/ to check what's actually available to build on, rather than guessing from op names alone, so the grouping below reflects what I found there.

Missing operators

Implementation notes

These vary a lot in difficulty. Some already have a clear path based on what's in the codebase:

• RNN, GRU, LSTM - no fused recurrent op in Relax, but the torch and tflite Relax frontends already implement LSTM by unrolling the recurrence with existing ops; the ONNX converter could follow the same pattern.
• CastLike, Swish - Relax has direct equivalents (astype, nn.silu) that cover the common case (default alpha=1.0 for Swish; standard dtype casts for CastLike). Non-default variants (float8 round_mode/saturate for CastLike, non-unit alpha for Swish) would need a small amount of extra composition.
• CumProd, ReverseSequence - Relax has ops covering the same purpose (cumprod, reverse_sequence), but attribute defaults/semantics differ from the ONNX spec (Relax's cumprod has no reverse mode; reverse_sequence's axis defaults are swapped relative to ONNX's time_axis/batch_axis), so the converter needs explicit attribute mapping rather than a pass-through.

Others (quantized conv/matmul, signal processing, Loop/Scan) likely need new compute/schedule work or, in the case of Loop/Scan, graph-level control-flow support. I'm not certain of the right approach here and would appreciate maintainer input.

Questions for maintainers

1. Is there an existing priority order for ONNX op coverage, or known user demand for any of the above from specific model families?
2. Are any of these considered out of scope or low priority for the Relax frontend (e.g. control flow, quantized ops, signal processing)?

Proposal

I'd like to pick up work on some of these, starting with the ones that have a clear implementation path (CastLike, Swish, ReverseSequence, CumProd attribute mapping, then RNN/GRU/LSTM via unrolling).

Questions for the maintainers

• Is there an existing priority order for ONNX op coverage, or known user demand for any of the above from specific model families?
• Are any of these (e.g. control flow, quantized ops, signal processing) considered out of scope or low priority for the Relax frontend?

Happy to pick up items above, split into smaller PRs by category, and help review PRs from others in this area as it progresses.

Triage

• needs-triage
• frontend:onnx
• status: RFC