[xyyy1420]

变更说明

本 PR 基于 riscv 分支，为两个 XSAI RISC-V vendor extension 增加 LLVM 后端支持：

• ZAMES（Attached Matrix Extension Simplified）：矩阵乘加子集，包含 msettile{m,n,k}、msetcfg/mgetcfg、矩阵 load/store、mzero 和单条 mmacc，使用 tr0–tr3 与 acc0–acc3。
• ZMASYNC（matrix asynchronous synchronization）：sync register 的 reset、release、acquire 和 fence；ZMASYNC 隐含前置需求 ZAMES。

主要修改：

模块	内容
Feature	新增 FeatureStdExtZames、FeatureStdExtZmasync；+zmasync 隐含 +zames
IR	新增 ZAMES/ZMASYNC intrinsics、tile/sync target extension types、立即数范围验证
MC	新增指令编码、汇编/反汇编、InstPrinter；新增 tr0–tr3、acc0–acc3、sync0–sync15、mcfg0–mcfg7
CodeGen	新增 RV64 SelectionDAG lowering、pre-RA 配置伪指令展开、post-RA 展开、矩阵内存操作数建模
测试	覆盖 IR verifier、MC、assembler/disassembler、CodeGen、MIR、feature list、Clang driver

由于 base 中 BOSC 与 ZAMES 共享 tr0/acc0 汇编名，RISCVAsmParser.cpp 中的寄存器 coercion 保留；

参考手册：

• ZAMES/ZMASYNC 规范：https://github.com/OurCompArchGroup/riscv-matrix-extension-spec/releases/tag/latest-93094fc8115795b41617d2ee6b73e0d3b75165f5

已知限制：

• 仅支持 RV64 代码生成；RV32 明确诊断。
• 不支持矩阵 copy/spill/reload 和跨函数 ABI。

验证方式

平台与构建：

• Host：Linux x86_64
• Target：riscv64（llc / llvm-mc）
• LLVM：24.0.0git 本地构建，启用 RISCV 与 X86 后端
• 构建命令：

 env CMAKE_BUILD_PARALLEL_LEVEL=128 \
 ninja -C llvm/build -j128 \
 llvm-mc llc llvm-objdump llvm-readelf clang FileCheck

ZAMES/ZMASYNC 测试：

 llvm/build/bin/llvm-lit -sv \
 llvm/build/test/Assembler/riscv-zames-intrinsics.ll \
 llvm/build/test/Verifier/riscv-zames-intrinsics-invalid.ll \
 llvm/build/test/MC/RISCV/zames.s \
 llvm/build/test/MC/RISCV/zames-invalid.s \
 llvm/build/test/MC/RISCV/zames-no-feature.s \
 llvm/build/test/MC/RISCV/zmasync.s \
 llvm/build/test/MC/RISCV/zmasync-invalid.s \
 llvm/build/test/MC/RISCV/zmasync-no-feature.s \
 llvm/build/test/MC/RISCV/zmasync-implies-zames.s \
 llvm/build/test/CodeGen/RISCV/zames \
 llvm/build/test/CodeGen/RISCV/features-info.ll

结果：23/23 PASS。

Clang driver：

 llvm/build/bin/llvm-lit -sv \
 llvm/build/tools/clang/test/Driver/print-supported-extensions-riscv.c

结果：PASS。

格式/空白检查：
git -C llvm diff --check
结果：clean。

检查清单

• the change is focused and contains no unrelated modifications.
• i have followed the target repository's contribution guidelines.
• i have added or updated tests where applicable.
• i have updated related documentation where applicable.
  • ZAMES/ZMASYNC 是 vendor extension；当前未修改 LLVM 文档，规范链接已放在 Summary。可后续补充文档。
• i have run the relevant formatting, lint, build, and test checks.
• i have described known limitations or compatibility impact.

[github-actions]

Hello @xyyy1420 👋

Thank you for submitting a Pull Request (PR) to the LLVM Project. Since this is your first PR, here are a few useful links covering our main contribution policies and review practices.

• All contributions to LLVM must follow our LLVM AI Tool Use Policy. In particular, if you used AI while working on this PR, remember to add a note to the PR description.
• The LLVM Code-Review Policy and Practices document contains practical information about the PR process, including how patches are reviewed and accepted, and who can review a PR.
• Our LLVM Developer Policy describes our expectations for code quality, commit summaries and contains notes on our CI system.

Please reply to this message to confirm that you have read these policies, especially the LLVM AI Tool Use Policy, and that any AI tool usage has been noted in the PR description.

---

Frequently asked questions

How do I add reviewers?

This PR will be automatically labeled, and the relevant teams will be notified. For some parts of the project, reviewers may also be added automatically.

You can also add reviewers manually using the Reviewers section on this page. If you cannot use that section, it is probably because you do not have write permissions for the repository. In that case, you can request a review by tagging reviewers in a comment using @ followed by their GitHub username.

What if there are no comments?

If you have not received any comments on your PR after a week, you can request a review by pinging the PR with a comment such as “Ping”. The common courtesy ping rate is once a week. Please remember that you are asking for volunteer time from other developers.

Are any special GitHub settings required to contribute to LLVM?

We only require contributors to have a public email address associated with their GitHub commits, see this section of LLVM Developer Policy for details.

---

If you have questions, feel free to leave a comment on this PR, or ask on LLVM Discord or LLVM Discourse.

Thank you,
The LLVM Community

[zhanghb97]

Thanks for the contribution!

Type System

The current implementation maps all ZAMES tile types (int8, fp8, fp16, bf16, and fp32) to a fixed 16 x i8 representation, while the corresponding register classes use different sizes (256 bits for tile registers and 1024 bits for accumulator registers).

Could you clarify the intended semantics of this underlying type representation?

In particular:

1. Is the 16 x i8 representation intended to describe the actual in-memory layout of a tile, or is it only a placeholder for an opaque hardware register resource?
2. If these types represent hardware register resources, do we need TargetExtType::CanBeLocal and TargetExtType::HasZeroInit? These properties may allow LLVM to treat them as local storage objects or support zero initialization, which does not necessarily match the intended register-only semantics.
3. How should DataLayout queries, alloca, memory operations, and zero initialization behave for these types?

I suggest explicitly defining the memory and storage semantics of these target extension types before exposing them to generic LLVM transformations. Otherwise, the current fixed-size representation may lead to inconsistent assumptions between LLVM IR and the RISC-V register allocation model.

Naming Consistency

One additional suggestion regarding naming consistency and vendor namespace management.

Since ZAMES/ZMASYNC are XSAI vendor extensions, I suggest including an explicit XSAI prefix in LLVM-internal names to avoid potential naming conflicts with other vendors' matrix extensions, especially given that this implementation already encounters register-name conflicts with BOSC AME.

For example:

• Intrinsics: llvm.riscv.xsai.zames.* and llvm.riscv.xsai.zmasync.*
• TargetExtType: riscv.xsai.ame.tile.* and riscv.xsai.ame.sync
• MVT and register definitions: riscv_xsai_ame_* and XSAI_ZAMES_*
• Pseudo instructions: PSEUDO_XSAI_ZAMES_*
• TableGen filenames: include XSAI in the relevant filenames.

The architectural extension names (ZAMES/ZMASYNC), instruction mnemonics, and -march feature names should remain consistent with the official ISA specification.

This would make the LLVM implementation more maintainable and provide a clearer vendor namespace for future extensions.

[zhanghb97]

License header wrong format: please follow 80-col limitation.

[xyyy1420]

License header wrong format: please follow 80-col limitation.

Fixed in 343a51a. The banner in the renamed XSAI file now fits within 80 columns. Thanks for pointing this out!

[zhanghb97]

License header wrong format: please follow 80-col limitation.

[xyyy1420]

License header wrong format: please follow 80-col limitation.

Fixed in 343a51a. The banner in the renamed XSAI file now fits within 80 columns. Thanks for pointing this out!

[zhanghb97]

License header wrong format: please follow 80-col limitation.

[xyyy1420]

License header wrong format: please follow 80-col limitation.

Fixed in 343a51a. The banner in the renamed XSAI file now fits within 80 columns. Thanks for pointing this out!

[zhanghb97]

License header wrong format: please follow 80-col limitation.

[xyyy1420]

License header wrong format: please follow 80-col limitation.

Fixed in 343a51a. The banner in the renamed XSAI file now fits within 80 columns. Thanks for pointing this out!

[zhanghb97]

The memory effects of ZMASYNC intrinsics need to be revisited.

Currently, all ZMASYNC intrinsics are defined with IntrNoMem and IntrHasSideEffects.

IntrHasSideEffects prevents the intrinsic from being treated as a pure operation, but it does not fully describe its ordering relationship with ordinary memory accesses.

In particular, mrelease and macquire are expected to provide release/acquire synchronization semantics. With IntrNoMem, LLVM is not informed that these operations impose ordering constraints on ordinary loads and stores.

For example:

• Stores preceding mrelease must not be reordered after the release operation.
• Loads following macquire must not be reordered before the acquire operation.
• mfence must enforce the memory ordering required by the hardware specification.

Please consider using appropriate memory effects (e.g. IntrReadWriteMem as a conservative starting point), or mapping these operations to LLVM's native atomic/fence semantics where applicable.

The corresponding MachineInstr definitions should also be reviewed to ensure that machine scheduling preserves the required ordering.

Please add optimization-level tests covering load/store motion across these synchronization intrinsics, rather than only testing instruction selection and encoding.

[xyyy1420]

Thanks for raising this. I checked the effective IR attributes and the machine-scheduling behavior; there are several layers of semantics to distinguish.

Hardware semantics

Specifically, mrelease increments the synchronization counter by one after the relevant matrix store completes. mfence provides the ordering needed for scalar/vector writes to become visible to subsequent matrix accesses.

With IntrNoMem, LLVM is not informed that these operations impose ordering constraints on ordinary loads and stores.

I checked how the LLVM revision used by this branch handles this combination of properties. In IntrinsicEmitter.cpp, when an intrinsic has both no-memory effects and IntrHasSideEffects, getEffectiveME() changes its effective memory effects to MemoryEffects::unknown().

Consequently, these intrinsics are not exposed to the optimizer as memory(none) operations; the current effective memory model is conservative. I agree that the TableGen spelling is confusing. The checks performed so far have not revealed a correctness issue, and the spelling can be clarified in a follow-up.

I also ran paired optimizer checks using the actual llvm.riscv.xsai.zmasync.mfence intrinsic:

• LICM: without the intrinsic, the load was hoisted out of the loop; with the intrinsic, the load remained inside the loop after it.
• DSE: without the intrinsic, the first of two stores to the same address was removed; with the intrinsic between the stores, both stores were retained.

These checks demonstrate the current conservative optimizer behavior.

Machine scheduling and regression tests

The synchronization instructions currently have hasSideEffects = 1. This is represented as unmodeled side effects, which makes TargetInstrInfo::isGlobalMemoryObject() classify them as barrier nodes in ScheduleDAGInstrs. Therefore, even with mayLoad = mayStore = 0, the scheduler adds barrier-chain dependencies for stores and non-invariant loads.

Coverage is still missing for the following scenarios:

• Scalar/vector store → mfence → matrix load;
• Matrix store → mrelease;
• Ordering of consumer accesses after acquire;
• The corresponding machine-scheduling constraints.

These test cases can be added in a follow-up.

[xyyy1420]

Thanks for the detailed review. I agree that the register-resource semantics of these types should be explicit.

In response to your review:

Type system

Is the 16 x i8 representation intended to describe the actual in-memory layout of a tile, or is it only a placeholder for an opaque hardware register resource?

The original representation was only a placeholder, not the intended in-memory layout. These types represent opaque hardware register resources carried through LLVM IR as SSA values. The fixed vector layout was indeed misleading.

I have changed the layout of all seven native matrix tile types and the synchronization type to void, making them unsized.

If these types represent hardware register resources, do we need TargetExtType::CanBeLocal and TargetExtType::HasZeroInit?

No. Both properties have been removed.

How should DataLayout queries, alloca, memory operations, and zero initialization behave for these types?

The contract is now:

• No ordinary memory layout, allocation size, or element stride is exposed. DataLayout queries requiring a sized type are not valid for these types.
• Generic alloca, byval, load, store, and GEP operations involving these unsized types are rejected.
• zeroinitializer is rejected.
• SSA use, including PHIs, remains valid IR. Supported matrix operations continue to use target-specific intrinsics and backend lowering.

I added coverage in llvm/test/Assembler/riscv-xsai-type-properties.ll to check that these invalid uses are rejected and that valid SSA use is preserved.

The property removal and unsized-layout changes are in c10ab12 and 5469e4b, respectively.

Naming consistency

Since ZAMES/ZMASYNC are XSAI vendor extensions, I suggest including an explicit XSAI prefix in LLVM-internal names to avoid potential naming conflicts with other vendors' matrix extensions, especially given that this implementation already encounters register-name conflicts with BOSC AME.

Agreed. I have added the XSAI namespace to the LLVM-internal intrinsic names, target extension types, MVTs, register definitions, pseudo opcodes, and relevant TableGen filenames, and updated the affected tests and callers.

The intrinsic namespaces are now:

• llvm.riscv.xsai.zames.*
• llvm.riscv.xsai.zmasync.*

The target extension types use:

• riscv.xsai.zames.tile.*
• riscv.xsai.zmasync.sync

Rather than placing both under a shared ame namespace, I kept matrix and synchronization resources under their respective extension namespaces to distinguish them clearly.

The architectural extension names, instruction mnemonics, and -march feature names are unchanged.

These changes are in 006120a and e6b128e.

Validation

After rebasing, all 33 tests in the selected LLVM/Clang/MLIR regression set passed.

The emitted .text bytes for the three representative integer, floating-point, and synchronization code-generation inputs are unchanged from before the changes.