Assessment of the difficulty in porting CPU architecture for Halide

[wangyuliu]

Hello everyone! I am working on implementing a tool to assess the complexity of CPU architecture porting. It primarily focuses on RISC-V architecture porting.In fact, it can be estimated on average across various architectures. As part of my dataset, I have collected the halide project. I would like to gather community opinions to support my assessment. I appreciate your help and response! Based on scanning tools, the porting complexity is determined to be high, with a moderate amount of code related to the CPU architecture in the project. Even if the developer has already completed the adaptation for a certain architecture, researching the adaptation work can still be challenging.It would require a professional person or team, but not a large-scale one, to handle this task (referring to the overall workload from adapting the project to a specific architecture to achieving full functionality on that architecture). Is this assessment accurate? I look forward to your help and response.

[abadams]

Are you working on assessing the complexity of CPU architecture porting for software in general, or the complexity of adding support for a new CPU architecture to a compiler?

Getting libHalide to compile on RISC-V without changing the capabilities of the compiler would be easy, but it would only be useful as a cross compiler to generate code for other architectures. Getting Halide to generate scalar RISC-V code is pretty straight-forward, because LLVM handles almost all of the complexity. Adding the ability for Halide to emit RISC-V code that makes use of the vector instructions was very hard.

[zvookin]

I did much of the work of adding RISC V support to Halide.

To clarify, amplify what Andrew wrote, and provide a couple soft data points:

I assume this is measuring the complexity of having the Halide compiler support RISC V, not effects on applications which use Halide. (A significant advantage of Halide is it significantly reduces the effort to adapt to new hardware, specifically around SIMD instructions.)

Without RISC V Vector support the effort was minimal. A couple days to a week's worth of effort with some ongoing maintenance. This is work is mostly adding enum values and wiring things up to LLVM.

RISC V vector support was much more effort. Probably rounds up to a person year or more once it is done. Part of this is that I started tracking RISC V Vector well before it was finalized. LLVM added a significant new IR feature in vscale vectors, for ARM SVE, and RISC V decided to use this as the basis for their vector support. After this, LLVM vector predicated intrinsics were added. All along there were issues at both the design and implementation levels which required effort to track and mitigate.

Another significant factor is a lack of working hardware to run our full test suite. It is prohibitively expensive to run all our tests under emulation.

Does the tool look at the GitHub commit history or only a snapshot of the source code. Some indication of the effort so far can be obtained from the commit history. Happy to provide more details if it is useful.