add-target-atom-op

Add target-specific MmaOp/CopyOp to a FlyDSL backend dialect.

260|104|Updated Nov 23, 2025
One-click install
npx skills add https://github.com/ROCm/FlyDSL --skill add-target-atom-op
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: add-target-atom-op
Source: https://github.com/ROCm/FlyDSL/tree/main/.claude/skills/add-target-atom-op
Command: npx skills add https://github.com/ROCm/FlyDSL --skill add-target-atom-op

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill provides a structured recipe to add a new target-specific MmaOp/CopyOp to a FlyDSL backend dialect, enabling support for new hardware backends and the associated lowering and wiring.

Core Features & Use Cases

  • Two-level type design: generic payloads in the fly dialect and backend payloads in the backend dialect (e.g., !fly.mma_atom and !fly_rocdl.cdna3.mfma)
  • Full interface implementation guidance: Fly_MmaOpTypeInterface, Fly_CopyOpTypeInterface, and optional stateful interfaces, plus example lowering paths (emitAtomCall, emitAtomCallSSA)
  • End-to-end roadmap: TableGen declarations, backend code, CMake, Python bindings, and tests to wire a new backend op (e.g., CDNA5_MFMA)

Quick Start

Follow the recipe to implement a new backend-specific MmaOp/CopyOp by declaring the payload types in the backend dialect, wiring up interface methods, adding lowering paths, and integrating build and Python bindings.

Frequently Asked Questions about add-target-atom-op

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I add a new hardware MmaOp or CopyOp to a FlyDSL backend dialect?

To add a new hardware MmaOp or CopyOp to a FlyDSL backend dialect, you declare backend payload types in TableGen, implement interface methods, wire lowering hooks, and integrate CMake to support custom intrinsics.

What is the two-level type design pattern for extending FlyDSL backends?

The two-level type design for extending FlyDSL backends uses generic payloads in the fly dialect, such as mma_atom, and backend-specific payloads in the backend dialect, such as rocdl cdna3 mfma, to separate abstract and target-specific operations.

How does lowering work for newly added backend operators in FlyDSL?

Lowering for newly added backend operators in FlyDSL works by implementing Fly_MmaOpTypeInterface or Fly_CopyOpTypeInterface methods and configuring lowering passes like emitAtomCall or emitAtomCallSSA to translate operations into hardware intrinsics.

Do I need to validate ThrVal and ThrBit layouts when adding a custom operator to FlyDSL?

Yes, you need to validate ThrVal and ThrBit layouts when adding a custom operator to FlyDSL to ensure safe and correct operation of the new target-specific MmaOp or CopyOp during backend lowering.

What's the best way to wire build system and Python bindings for a new FlyDSL backend op?

The best way to wire build system and Python bindings for a new FlyDSL backend op is to follow the end-to-end roadmap, integrating CMake configurations and Python bindings alongside the TableGen declarations and backend code.

Can I introduce optional SSA lowering paths for custom FlyDSL hardware intrinsics?

Yes, you can introduce optional SSA lowering paths for custom FlyDSL hardware intrinsics by implementing stateful interfaces and utilizing lowering paths like emitAtomCallSSA alongside the standard lowering passes.