Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Thursday October 05 2017, @12:12PM   Printer-friendly
from the please-let-the-vapors-condense dept.

From the lowRISC project's blog:

A high quality, upstream RISC-V backend for LLVM is perhaps the most frequently requested missing piece of the RISC-V software ecosystem… As always, you can track status here and find the code here.

RV32

100% of the GCC torture suite passes for RV32I at -O0, -O1, -O2, -O3, and -Os (after masking gcc-only tests). MC-layer (assembler) support for RV32IMAFD has now been implemented, as well as code generation for RV32IM.

RV64

This is the biggest change versus my last update. LLVM recently gained support for parameterising backends by register size, which allows code duplication to be massively reduced for architectures like RISC-V. As planned, I've gone ahead and implemented RV64I MC-layer and code generation support making use of this feature. I'm happy to report that 100% of the GCC torture suite passes for RV64I at O1, O2, O3 and Os (and there's a single compilation failure at O0). I'm very grateful for Krzysztof Parzyszek's (QUIC) work on variable-sized register classes, which has made it possible to parameterise the backend on XLEN in this way. That LLVM feature was actually motivated by requirements of the Hexagon architecture - I think this is a great example of how we can all benefit by contributing upstream to projects, even across different ISAs.

[...] Community members Luís Marques and David Craven have been experimenting with D and Rust support respectively.

[...] Approach and philosophy

As enthusiastic supporters of RISC-V, I think we all want to see a huge range of RISC-V core implementations, making different trade-offs or targeting different classes of applications. But we don't want to see that variety in the RISC-V ecosystem result in dozens of different vendor-specific compiler toolchains and a fractured software ecosystem. Unfortunately most work on LLVM for RISC-V has been invested in private/proprietary code bases or short-term prototypes. The work described in this post has been performed out in the open from the start, with a strong focus on code quality, testing, and on moving development upstream as quickly as possible - i.e. a solution for the long term.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by Wootery on Friday October 06 2017, @06:38PM

    by Wootery (2341) on Friday October 06 2017, @06:38PM (#578217)

    one of its guiding design principles is that you shouldn't have to pay for a feature you don't use

    Generally true, but LLVM's coding standards ban RTTI and exceptions, precisely to avoid bloating their binaries. They even rolled their own alternative to RTTI.

    https://llvm.org/docs/CodingStandards.html#do-not-use-rtti-or-exceptions [llvm.org]

    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2