Skip to content

fix(ops): select active implementation for configless calls - #910

Draft
voltjia wants to merge 1 commit into
masterfrom
fix/select-active-implementation-by-default
Draft

fix(ops): select active implementation for configless calls#910
voltjia wants to merge 1 commit into
masterfrom
fix/select-active-implementation-by-default

Conversation

@voltjia

@voltjia voltjia commented Aug 7, 2026

Copy link
Copy Markdown
Collaborator

Summary

  • Make configless C++ Operator::Make and Operator::Call select the first active implementation for the input device.
  • Resolve that default index inside the built library, where backend specializations are visible to installed-header consumers.
  • Cover tensor, tensor-list, return-value, slot 0, and nonzero-slot paths without changing explicit Config behavior.

Motivation

Generated Python bindings already choose the first active implementation when a caller omits implementation_index. The configless C++ convenience overloads instead constructed Config{}, which always selected slot 0. Operators implemented only by a linked provider at slot 16 therefore failed even though a valid implementation was active.

The default cannot be derived from ActiveImplementations in a downstream translation unit because installed public headers do not expose backend specializations. This change emits one scalar resolver instantiation per operator in an implementation-visible generated source file and only declares it in the installed header.

N/A - no linked issue.

Type of Change

  • feat - new feature / new operator / new platform
  • fix - bug fix
  • perf - performance improvement
  • refactor - code restructuring without behavior change
  • test - adding or fixing tests only
  • docs - documentation only
  • build / ci - build system or CI configuration
  • chore - tooling, formatting, or other non-code changes
  • Breaking change

Platforms Affected

  • CPU (WITH_CPU)
  • NVIDIA (WITH_NVIDIA)
  • Iluvatar (WITH_ILUVATAR)
  • MetaX (WITH_METAX)
  • Cambricon (WITH_CAMBRICON)
  • Moore (WITH_MOORE)
  • Ascend (WITH_ASCEND)
  • Hygon (WITH_HYGON)
  • PyTorch C++ bindings (WITH_TORCH)
  • Build system / CMake / CI
  • Python bindings / user-facing API

Smoke Test Result

Remote environment: ssh nvidia, accelerator-dev/nvidia:latest, PyTorch 2.10.0a0+b4e4ee8.

INFINI_RT_ROOT=/opt/infinirt scripts/dev/build.sh nvidia --smoke --jobs 16
[build] done

python3 -m pytest tests -m smoke -q
123 passed, 18 skipped, 13904 deselected

The smoke allowlist is unchanged.

Focused Test Results

tests/test_generate_wrappers.py
25 passed

Installed <infini/ops.h> configless C++ consumer test
1 passed

The installed consumer test uses the real generated Abs slot 8 path for configless Make and Call. Existing Add coverage exercises slot 0 and CallReturning; a test-only slot 16 operator covers tensor-list descriptor construction.

The remote consumer compiler temporarily suppressed deprecation warnings emitted by legacy operators already present in the smoke-generated umbrella header. No deprecation behavior is changed in this PR.

Benchmark / Performance Impact

The default implementation query returns a scalar and runs only while entering a configless API. It does not allocate a vector and does not change kernel execution.

Notes for Reviewers

  • Only overloads without a Config derive a default from the device's active implementations.
  • Make(config, ...) and Call(handle, config, ...) still honor the exact requested index and never fall back.
  • Configless Make keeps its public forwarding-reference signature and normalizes only the internal generated-factory call to the existing const T& explicit instantiations.
  • CallReturning is covered because it delegates to configless Call after allocating the return tensor.

@voltjia
voltjia force-pushed the fix/select-active-implementation-by-default branch from 871deaf to e7b9e38 Compare August 7, 2026 19:12
@voltjia
voltjia force-pushed the fix/select-active-implementation-by-default branch from e7b9e38 to b43e564 Compare August 8, 2026 00:43
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