I’d like to propose adding support for the MIPS P8700 CPU to LLVM.
The P8700 is a high-performance processor from MIPS designed to meet the demands of modern workloads, offering exceptional scalability and efficiency. It builds on MIPS’s established architectural strengths while introducing enhancements that set it apart. If you’re interested in the details, you can check out the official product page here: MIPS P8700. For a broader perspective on the P8700’s goals and capabilities, this blog post might also be a good read.
On the user-space side, the P8700 essentially implements the RISC-V ISA, operating in a 64-bit mode (rv64imafdc) and enabling support for the Zba and Zbb extensions. When it comes to MIPS custom extensions, the P8700 introduces two new instructions:
Conditional move (+xmipscmov)
Load/store pair instruction (+xmipslsp)
Support for these instructions has been integrated into the LLVM pull request, which you can find here: PR for MIPS P8700.
As part of our broader efforts, we plan to start upstreaming support for the P8700 across other key projects like Linux, Binutils, and more. This is just the beginning of bringing this CPU into the wider ecosystem, and we’re excited to collaborate with the community to make it happen.
Feedback is, of course, welcome. Let us know your thoughts or if there are any considerations we should take into account as we move forward!
Hi Djordje - I just wanted to say thank you for writing this up along with the patch and that it’s great to see more vendors contributing upstream to RISC-V LLVM.
I think the best next step is to clean up and split the work into separate PRs that can be reviewed separately and landed incrementally one by one (and based on your comment in that PR, I think that’s your plan - great!). Specifically, a patch like " [RISCV] Add MIPS extensions " needs to be split into separate PRs for the different extensions, and we typically land the MC layer first and then add codegen. Hopefully people interested in Zilsd can become involved in the reviewing of xmipslsp as it would be good to review with both in mind.
Hi @asb, thanks a lot for your feedback and for taking the time to review the patch!
I think the best next step is to clean up and split the work into separate PRs that can be reviewed separately and landed incrementally one by one (and based on your comment in that PR, I think that’s your plan - great!). Specifically, a patch like " [RISCV] Add MIPS extensions " needs to be split into separate PRs for the different extensions, and we typically land the MC layer first and then add codegen. Hopefully people interested in Zilsd can become involved in the reviewing of xmipslsp as it would be good to review with both in mind.
Yes, that is indeed the plan. The PR and RFC were intended as an initial step.
Thanks for pointing this out! I’ll make sure to submit a PR for the vendor prefix and ensure the xmips* instructions use it appropriately.
I’m curious about the decision to disable the inline assembler, but that’s maybe best discussed on the appropriate PR once you split things up.
This was introduced due to a bug in the integrated assembler at the time. The issue was addressed, and the assembler support will be re-enabled in the dedicated PR.
