Skip to content

feat!: [codex] support polymorphic handles and configs - #917

Draft
voltjia wants to merge 1 commit into
masterfrom
codex/polymorphic-handle-config
Draft

feat!: [codex] support polymorphic handles and configs#917
voltjia wants to merge 1 commit into
masterfrom
codex/polymorphic-handle-config

Conversation

@voltjia

@voltjia voltjia commented Aug 10, 2026

Copy link
Copy Markdown
Collaborator

Summary

  • Add a reusable Cloneable<Base, Derived> CRTP helper for concrete Config and Handle subclasses.
  • Give Config and Handle virtual destructors and virtual Clone() methods while keeping both base classes concrete.
  • Replace the two sliced OperatorBase value members with owned std::unique_ptr clones; existing set_config(const Config&) and set_handle(const Handle&) signatures stay unchanged.
  • Add a focused installed-header C++ smoke test covering derived state, base state, clone independence, and source-object lifetime.

Motivation

Operator-specific options currently have to be added to the shared src/config.h, because assigning a derived Config or Handle to OperatorBase slices its dynamic state. This PR provides only the ownership mechanism needed for operator-specific subclasses.

This change is deliberately independent of #800 and contains no Triton/JIT, cache-key, constructor-dispatch, or handle-borrowing optimization changes.

Type of Change

  • feat - polymorphic Config and Handle ownership
  • fix - bug fix
  • perf - performance improvement
  • refactor - code restructuring without behavior change
  • test - focused C++ API coverage
  • docs - documentation only
  • build / ci - build system or CI configuration
  • chore - tooling, formatting, or other non-code changes
  • Breaking change

Platforms Affected

The shared public types and OperatorBase are used by every backend.

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

Smoke Test Result

Validated from commit 8142a511cf9cdac79d31f2247750a3344c2f7c20:

g++ -std=c++17 -Werror -Isrc -fsyntax-only <generic Cloneable probe>
# passed

python3 -m py_compile tests/test_cpp_api.py
# passed

clang-format 21.1.8 --dry-run --Werror \
  src/cloneable.h src/config.h src/handle.h src/operator.h
# passed

ruff 0.15.22 format --check tests/test_cpp_api.py
ruff 0.15.22 check tests/test_cpp_api.py
# passed

GitHub Actions provides the installed-library and backend build/run coverage. All required checks passed, including clang-format, Ruff, documentation build, and unit plus shadow jobs for NVIDIA, Iluvatar, MetaX, Moore, Cambricon, and Ascend.

Test Results on Supported Platforms

Platform Affected Build / Smoke Result Full Result / Notes
CPU yes local C++17 API syntax probe passed installed-library smoke covered by backend CI
NVIDIA yes unit and shadow CI passed passed
Iluvatar yes unit and shadow CI passed passed
MetaX yes unit and shadow CI passed passed
Cambricon yes unit and shadow CI passed passed
Moore yes unit and shadow CI passed passed
Ascend yes unit and shadow CI passed passed

Benchmark / Performance Impact

No performance optimization is included.

Config is cloned when an operator is constructed, which normally happens on a cache miss. The existing invocation path calls set_handle() for every invocation; after this change that performs one virtual Clone(), one derived-object copy, and one heap allocation per call. A borrowed-handle fast path can be evaluated separately without coupling it to the polymorphism API.

Notes for Reviewers

  • This is ABI-breaking: Config and Handle gain virtual tables, and the protected OperatorBase::config_ / handle_ members change from values to std::unique_ptr.
  • Concrete CRTP subclasses must be final; Cloneable enforces this when Clone() is instantiated.
  • The base Config and Handle classes remain directly constructible and clone themselves by default.
  • There is no production RTTI, dynamic type hash, or config fingerprint in this PR.
  • Cache-key behavior is unchanged. An operator whose derived Config fields affect cached behavior must include those fields explicitly in its existing CacheKeyBuilder<Key> specialization.
  • set_config() and set_handle() remain replaceable, matching the previous setter semantics; no one-time initialization rule is added.

@voltjia
voltjia force-pushed the codex/polymorphic-handle-config branch from f9a26ee to 8142a51 Compare August 11, 2026 03:37
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