Compiling with clang

HiFive1 Rev B
1

Hello!

So i wanted to try out clang compiler performance and compare it to gcc performance on my hifive1.
I wonder if there is anyone else who have done this before? Because I have some issues.

Since riscv-llvm currently only support .c->.S i still use GCC as a linker though. I’ve got it to compile by replacing C_SRCS in the makefiles with a local _C_SRCS and made a target for compiling .c files to .S files with clang and then added the generated .S files to ASM_SRCS instead.

I got the “hello” and “led_fade” examples to work fine but do have some issues with coremark and dhrystone which both ends up with a trap and exitcode 0x8 which i have no idea what it means.

I have not gotten run_debug to work since it crashes before gdb has a change to attach it seems.

Anyone else want to give this a shot or have some ideas on how I could go by debugging this?

Thanks in advance

2

Maybe a lot easier to make a small shell script that uses clang to compile to .S and then as to assemble to .o. Then the only thing you have to change in makefiles is CC.

I believe clang support for risc-v is quite immature. And there is an old clang back end that is I think more or less abandoned (but more or less works), and a new one that does not yet work.

3

Thanks for the reply.

Maybe a lot easier to make a small shell script that uses clang to compile to .S and then as to assemble to .o. Then the only thing you have to change in makefiles is CC.

That’s essentially what I’m doing but it’s done in my Makefile which is cleaner. Since it needs the same includes as GCC it would just be duplication if I would put it in a separate shell script.

I believe clang support for risc-v is quite immature. And there is an old clang back end that is I think more or less abandoned (but more or less works), and a new one that does not yet work.

By “old clang backend” and a “new one that does not yet work” do you mean that the old one is the “RISCV” branch and the new one to be “riscv-trunk” from GitHub - ucb-bar/esp-llvm: UCB-BAR fork of LLVM! NOT UPSTREAM RISCV LLVM?

I am currently using the riscv-trunk branch so I’ll start with trying switching to the RISCV branch then.

4

Alright i now tested the RISCV branch instead of the riscv-trunk branch of llvm. The hello example still compiles and works but both coremark and dhrystone make the whole compiler crash…

Invalid branch condition code!
UNREACHABLE executed at /home/johan/riscv/riscv-llvm/lib/Target/RISCV/RISCVInstrInfo.cpp:382

5

Since the riscv-trunk branch didn’t work and the RISCV branch obviously didn’t work i tried the last commit from riscv-trunk that passed their travis tests (871363, July 21st 2016) but that crashes in the same manner as the upstream riscv-trunk so that didn’t work either.

6

I had the same problem and I found it was due to calling convention mismatch. (I needed gdb for this.)
I myself could not fix the bug but I found the fix in the issue tickets;

And today I’ve just post a tip to compile by only clang on a ticket posted a long time ago;

$ cd .../freedom-e-sdk/software/dhrystone
$ make CC="riscv32-unknown-elf-clang --sysroot=/opt/riscv/r32" dhry_1.o dhry_2.o dhry_printf.o dhry_stubs.o OPT=-O3
$ make

results;

Dhrystones per Second: 41666.6

I have to run make twice because clang cannot compile start.S.
Performance is less than 1/10 of one of gcc -O3.

coremark also runs;

core freq at 260253286 Hz
2K performance run parameters for coremark.
CoreMark Size    : 666
Total ticks      : 1451359
Total time (secs): nan
Iterations/Sec   : nan
Iterations       : 10000
Compiler version : GCC4.2.1 Compatible Clang 3.8.0
Compiler flags   : -O2 -fno-common -funroll-loops -finline-functions --param max-inline-insns-auto=20 -falign-functions=4 -falign-jumps=4 -falign-loops=4
Memory location  : STACK
seedcrc          : 0xe9f5
[0]crclist       : 0xe714
[0]crcmatrix     : 0x1fd7
[0]crcstate      : 0x8e3a
[0]crcfinal      : 0x988c
Correct operation validated. See readme.txt for run and reporting rules.
trap

Progam has exited with code:0x00000006

CRC results are OK. But “Total ticks” and “Total time” value is wrong. Floating point library may not work well.

7

riscv clang is known to be immature and unstable and no one uses it. gcc works well.

The place to post about clang would be to raise issues on the project’s github.

8

Thanks a lot @sflin!

Using the caller-saved-fix branche mentioned in the first issue didn’t compile for me, but i merged it with riscv-trunk and now coremarks runs and finishes! (duration becomes NaN though, but atleast it runs). I made a fork of it here https://github.com/johan-bjareholt/riscv-llvm

It actually fixes Dhrystone aswell but it’s very slow like you said. Dhrystone neither gets the duration correct so it’s possibly something bad with floating point operations.

Next i will look at the patches in the second issue you linked and hopefully get the timing working. Thanks a bunch for the help!