flaggems-integration

Run torchgen-based discovery with codegen_ops.py in the exact build environment, regenerate wrappers and platform conf files together, then validate each routed overload against a CPU reference on hardware. Routing presence alone is not operator support.

Python routes use the flagos_python backend discovered from flag_gems._FULL_CONFIG, while the C++ path routes a small explicit kernel set without the Python GIL. Both are per-op keys inside one platform conf, selected with flaggems or flaggems_cpp values.

Yes, FlagGems and CUDA boxing may coexist per operator, and native backends handle operators FlagGems cannot express. Establish the boxing or native path first, then route additional operators to FlagGems with documented fallback policy.

Non-idempotent output usually comes from unordered discovery, unstable config ordering, embedded timestamps, or a mutable FlagGems registry. Fix the generator in codegen_ops.py rather than editing generated files, then confirm two runs produce identical patches.

Import success and routing table entries only indicate candidates for testing. Support verdicts come from the overload survey, which executes synthesized cases against a CPU reference and classifies operators as STRICT, BASIC_ONLY, FAILED, or UNTESTED.

Do not use FlagGems when the vendor API cannot be expressed by its kernels or when the platform compiler cannot run the route. Route that operator through the CUDA-compatible or native backend and document the boundary instead of handwriting bypass kernels.