[RISCV] Introduce RVI AME (standard, pre-ratification) backend support

[vismaysur]

This PR adds initial RISC-V AME backend support.

Tasks/Deliverables:

• target feature support (subtarget features for AME_NUM_M_REGS and AME_NUM_ACC_REGS)
• matrix register definitions
• instruction definitions + encodings
• intrinsics
• tests: llc (.ll -> .s and .ll -> .o) and llvm-mc (.s -> .o).

Closes #21

[github-actions]

Hello @vismaysur 👋

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

[vismaysur]

A few important observations / notes:

• mls.rm / mls.cm / mls instructions (for loading squares) have no stride operands (encoding only the destination reg index and the base mem addr). so they can only load tiles that are already contiguous in memory (rather than extracting tiles out of a larger strided row-major / column-major matrix).

Just a detail to keep note of: if a stride operand is later added to the spec, we will not need to repack data in memory into tiles.

[zhanghb97]

A few important observations / notes:

• mls.rm / mls.cm / mls instructions (for loading squares) have no stride operands (encoding only the destination reg index and the base mem addr). so they can only load tiles that are already contiguous in memory (rather than extracting tiles out of a larger strided row-major / column-major matrix).

Just a detail to keep note of: if a stride operand is later added to the spec, we will not need to repack data in memory into tiles.

Good catch. We will keep our design aligned with the RVI specification and make the corresponding changes if the specification is updated.

[zhanghb97]

Please rebase the PR. I will start the review today.

[vismaysur]

Note: BOSCAME backend seems to instruction select LLVM IR to pseudo instructions (with immediate operands) which are then directly printed as asm, with no path (as i understand it) to MCInstr encodings / .o output. it has real instruction encodings but these are only reachable from .s or .o inputs, not from LLVM IR (please clarify if my understanding is incorrect).

Since M/Acc indices are already assigned by MLIR before they reach LLVM, so encoding them as immediates (rather than encoding register class operands) lets ISel lower straight to the real, bit-encoded instruction. I took a slightly different path in this backend of omitting the pseudo instructions altogether, instead encoding real instructions with immediate operands, enabling a single path from LLVM IR -> MCInstr with real encodings -> both .o and .s outputs.