Skip to content

Latest commit

 

History

History
228 lines (158 loc) · 9.63 KB

gap-analysis.adoc

File metadata and controls

228 lines (158 loc) · 9.63 KB
Raw

Toolchains SIG

This page lists gaps that have been identified by the Toolchains SIG and are planned to be addressed for 2024.

The gaps have the following properties:

  • Title

  • Tags

  • Description

  • Status

  • Ticket (if existing)

Gaps backlog

psABI: ABI versioning/breakage

  • Tags: psABI

  • Description: ABI breaks become inevitable at one point. We need to ensure to have a proper versioning scheme and being able to enforce that.

  • Status: Open

psABI: Alignment Relocation

psABI: Flexible eABI

  • Tags: psABI, eABI

  • Description: Design flexible ABI for optimizing different embedded system applications. Embedded application might has different requirements than the Linux or *BSD environment, and embedded world also have very diversity requirements, so we intend to not just define a single ABI for all embedded system, and define

  • Ticket: riscv-non-isa/riscv-elf-psabi-doc#305

  • Status: Open

psABI: ePIC

  • Tags: psABI

  • Description: medlow and medany only provide limited capability to access the address space, capability to access the whole address space is useful for specific areas. We need a code mode that has the capability to access the full address space.

  • Status: open

psABI: runtime library ABI

  • Tags: psABI

  • Description: LLVM / compiler-rt has had inconsistent helper function names for fp16 types with gcc/libgcc for a while, and fixed that later, but why this happened is because we don’t have a standard document to follow. We need to specify the interface and semantics of compiler helper functions in libgcc/compiler-rt, we don’t have a formal specification on that, but having a de-facto standard on libgcc and compiler-rt, we need to document that down.

  • Status: open

  • Link: https://github.com/ARM-software/abi-aa/tree/main/rtabi32

psABI: vendor relocation

  • Tags: psABI

  • Description: psABI has defined a range of relocation for non-standard use, but didn’t have a complete solution to prevent collision between different vendor relocations. Vendors might define their own custom instruction which require relocation, e.g. new branch instruction, new load/store instruction with different immediate bits.

  • Status: open

psABI: Alignment of __int128 on ILP32

  • Tags: psABI

  • Description: The alignment of __int128 is defined on LP64 but not on ILP32.

  • Status: open

psABI: ILP32E/ILP64E

psABI: Optional Redzone

  • Tags: psABI

  • Description: Redzones provide some performance opportunity (e.g. eliding frame setup for leaf functions), and provide an escape hatch for compiler implementations (e.g. for having a scratch register available.) The RISCV ABI is currently specified without a redzone. Adding one in a backwards compatible manner would require some form of marker in the ELF file, and enforcement in the dynamic loader.

  • Status: Open

psABI: Stack frame layout

  • Tags: psABI

  • Description: Portability requires a defined stack frame layout. It’s different from existing systems (so code needs risc-v-specific changes), but it’s not currently documented.

  • Ticket: riscv-non-isa/riscv-elf-psabi-doc#18

  • Status: Open

psABI: TLSDESC relocations

  • Tags: psABI

  • Description: emutls is broken for rv64 (at least in llvm) 🙂and although rv64 could be the first Android architecture to use ELF TLS rather than emutls by default (because it’s the first one to come after we added ELF TLS to the system), it’s a shame we can’t use TLSDESC relocations for that.

  • Ticket: riscv-non-isa/riscv-elf-psabi-doc#94

  • Status: open

psABI: ilp32 for RV64

  • Tags: psABI

  • Description: ILP32 has three use-cases 1) vserver hosting (memory bound), 2) netbooks/tablets (low memory, want performance), and 3) scientific tasks (want every % of performance).

  • Link: https://wiki.debian.org/X32Port

  • Status: open

Mapping symbol

Relocation for ULEB128

  • Tags: psABI

  • Description: ULEB128 are widely used now, and the ULEB128 will be used for encoding the address difference. Dwarf has some fields that only support uleb128, which might cause problems if we don’t have relocation to those fields when relaxation enabled.

  • Ticket: riscv-non-isa/riscv-elf-psabi-doc#162

  • Status: open

Fine-grained cost model

  • Tags: Compilers, Performance

  • Description: The backend of GCC lacks a fine-grained cost model to optimize code generation for specific cores.

  • Status: Open (even if the current cost model in the compilers is simplified, we need actual HW to drive this effort)

Embedded ABI

  • Tags: psABI

  • Description: There have been multiple attempts to establish an embedded ABI. In recent discussions a parameterized ABI has been proposed, which allows to provide a flexible ABI framework that’s suitable for all needs.

  • Status: Open

Matrix intrinsics

  • Tags: C API

  • Description: RVI drives efforts for two matrix extensions. Both need intrinsics support.

  • Status: Open

Matrix primitives API

  • Tags: C API

  • Description: RVI drives efforts for two matrix extensions. A common primitives API could be considered.

  • Status: Open

Gaps for 2024

psABI: Pointer masking

  • Tags: psABI

  • Description: We need to specify the details of pointer masking to ensure correctness and interoperability

  • Status: Open

psABI: _BitInt ABI

Function attributes

  • Tags: C API

  • Description: We need to specify a few function attributes (vector CC, prestacking, multi-versioning) to ensure interoperability.

  • Status: Open

Profiles support

Utilize ifunc support

  • Tags: Runtimes, Performance

  • Description: Glibc offers an indirection mechanism to call target-specific implementations for functions like strlen, strcmp, memcmp. Upstream glibc does not untilize this mechanism and uses therefore unoptimized implementations (Zb*, V, Zawrs).

  • Status: Open (Linux has added a mechanism to dynamically detect available extensions as runtime (hwprobe). This allows to include ifunc-optimizations on top of that.)

Cleanup of C-API, ASM manual, toolchain conventions

  • Tags: Cleanup

  • Description: Migration from Markdown to ASCIIdoc; adoption of RVI template; CI to build PDF (same like psABI)

Gaps for 2023

psABI: Atomics ABIs

  • Tags: psABI

  • Description: Document atomics ABI (for A and Ztso) to ensure correctness and interoperability

  • Status: Done (atomics ABIs have been defined and implemented)

psABI: Vector ABI(s)

Auto-vectorization

  • Tags: Compilers, Performance

  • Description: The (recently ratified) RISC-V vector extension allows to utilize and extend GCC’s auto-vectorization capabilities. Currently, there is no (public information about) active work in this area.

  • Status: Both major compilers (GCC and LLVM) support auto-vectorization as of end 2023

Vector intrinsics

  • Tags: Compilers

  • Description: Besides auto-vectorization, RISC-V vector instructions should be emitted by compilers via an extensions of the C language (intrinsics).

  • Status: RVV intrinsics TG has been formed that works on the specification. As of Apr 2024 the spec is close to ratification and implemented in GCC and LLVM.

Bitmanip + scalar crypto intrinsics

  • Tags: Compilers, C-API

  • Description: Zb* extensions have been ratified a while ago. We need to agree on intrinsics and implement them.

  • Ticket: riscv-non-isa/riscv-c-api-doc#44

  • Status: Intrinsics have been defined and implemented in GCC and LLVM

LLVM support in riscv-gnu-toolchain scripts

  • Tags: Compilers

  • Description: The riscv-gnu-toolchain scripts only supports GCC. We should add LLVM support as well.

  • Status: LLVM support has been merged

Gaps for 2022

Basic vector support

  • Tags: Compilers

  • Description: The RISC-V vector extension needs basic support in GCC (compiler flags support, intrinsics support, tests).

  • Status: Both major compilers (GCC and LLVM) have basic vector support as of end 2022