[llvm-dev] RISC-V runtime support functions

[Thomas Goodfellow via llvm-dev]

Compiling for RISC-V, clang makes appropriate use of mem*() functions for bulk operations such as initialisation:

********

// test.c

int main() {
        int a[16] = { 0 };
        return a[0];
}

$ clang test.c -c --target=riscv32 -march=rv32i -mabi=ilp32

$ llvm-objdump --syms test.o

test.o: file format elf32-littleriscv

SYMBOL TABLE:
00000000 l    df *ABS*  00000000 test.c
00000000 g     F .text  0000003c main
00000000         *UND*  00000000 memset

********

Unlike integer helper routines such as __divsi3, the mem* functions are not supplied by compiler-rt. I would naively expect them to come from libc. Some questions:

(1) Is there a way to have the compiler provide substitutes, e.g. naive built-in implementations?

(2) I didn't successfully build llvm-libc for RISC-V, e.g. configuring as:

cmake -DLLVM_TARGETS_TO_BUILD='RISCV' -DLLVM_ENABLE_PROJECTS='clang;lld;compiler-rt;libc'  /* other options */

built lib/libllvmlibc.a as elf64-x86-64, and specifying as -DLLVM_ENABLE_RUNTIMES="libc" triggered asserts in the 'X86 FP Stackifier' pass while building LLVM. Is there a way to build llvm/libc for RISC-V?

(3) If llvm/libc isn't buildable for a RISC-V baremetal target, what is the best way to supply the missing mem* functions? E.g.:

(a) are there problems with using the Newlib-based library in riscv-gnu-toolchain for this? (the OS-dependent functions that use ecall instructions won't be supported but hopefully mem*, str*, math.h, etc, all work.) (b) Picolibc (https://keithp.com/picolibc/) looks like another possibility?

(c) or just provide (naive) implementations, e.g. textbook implementations in 'C'?

[Jessica Clarke via llvm-dev]

On 26 Jan 2022, at 08:35, Thomas Goodfellow via llvm-dev <llvm...@lists.llvm.org> wrote:
>
> Compiling for RISC-V, clang makes appropriate use of mem*() functions for bulk operations such as initialisation:
>
> ********
> // test.c
> int main() {
> int a[16] = { 0 };
> return a[0];
> }
>
> $ clang test.c -c --target=riscv32 -march=rv32i -mabi=ilp32
> $ llvm-objdump --syms test.o
> test.o: file format elf32-littleriscv
>
> SYMBOL TABLE:
> 00000000 l df *ABS* 00000000 test.c
> 00000000 g F .text 0000003c main
> 00000000 *UND* 00000000 memset
> ********
>
> Unlike integer helper routines such as __divsi3, the mem* functions are not supplied by compiler-rt. I would naively expect them to come from libc. Some questions:
>
> (1) Is there a way to have the compiler provide substitutes, e.g. naive built-in implementations?

No. If you don’t compile with -ffreestanding then Clang will assume you have a full libc implementation per the C standard. If you compile with -ffreestanding then, like GCC, it will still require memcpy, memset, memmove and memcmp. This is technically wrong but not doing so would lead to extreme code bloat on architectures that don’t have native instructions for those operations.

> (2) I didn't successfully build llvm-libc for RISC-V, e.g. configuring as:
>
> cmake -DLLVM_TARGETS_TO_BUILD='RISCV' -DLLVM_ENABLE_PROJECTS='clang;lld;compiler-rt;libc' /* other options */
>
> built lib/libllvmlibc.a as elf64-x86-64, and specifying as -DLLVM_ENABLE_RUNTIMES="libc" triggered asserts in the 'X86 FP Stackifier' pass while building LLVM. Is there a way to build llvm/libc for RISC-V?

I don’t know if LLVM libc supports RISC-V, but yes, -DLLVM_ENABLE_PROJECTS will give you a native build of those projects; -DLLVM_ENABLE_RUNTIMES, or building the project separately as its own CMake project pointing at your just-built Clang, is how it would work if it did. Assertion failures in the X86 FP Stackifier pass don’t make much sense though.

> (3) If llvm/libc isn't buildable for a RISC-V baremetal target, what is the best way to supply the missing mem* functions? E.g.:
> (a) are there problems with using the Newlib-based library in riscv-gnu-toolchain for this? (the OS-dependent functions that use ecall instructions won't be supported but hopefully mem*, str*, math.h, etc, all work.) (b) Picolibc (https://keithp.com/picolibc/) looks like another possibility?

Newlib works fine and is the normal thing people use. Never tried picolibc but provided it supports RISC-V there should be no reason why it wouldn’t work.

> (c) or just provide (naive) implementations, e.g. textbook implementations in 'C'?

Also works fine.

Jess

_______________________________________________
LLVM Developers mailing list
llvm...@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev