The latest version of llc generates an asm file that automatically adds zicsr2p0 to the .attribute

Beginners
1

I used the same .ll file.
Here is the assembly file generated with the latest llc.

 .text
        .attribute      4, 16
        .attribute      5, "rv64i2p1_f2p2_d2p2_zicsr2p0"
        .file   "LLVMDialectModule"
        .globl  main                            # -- Begin function main
        .p2align        2
        .type   main,@function

Here is the llc I used before.

 .text
        .attribute      4, 16
        .attribute      5, "rv64i2p0_f2p0_d2p0"
        .file   "LLVMDialectModule"
        .globl  main                            # -- Begin function main
        .p2align        2
        .type   main,@function

A problem arises here.Here are the problems I encountered when linking.The version of riscv64-unknown-linux-gnu-gcc is 9.2,but I didn’t want to change it.

riscv64-unknown-linux-gnu/bin/ld: -march=rv64i2p1_f2p2_zicsr2p0: unsupported ISA subset `z'

In addition to this, there is an interesting point.To solve this problem.This is how I use llc. (I’m running the program on spike, I have to make -float-abi=hard and use the D extension),I want to remove the Z extension manually.

$:  buddy-llc main.ll -filetype=asm -mtriple=riscv64 \
                -mattr=+D,-zicsr -float-abi=hard \
                -o main.s

But when I looked at main.s, I found that the D extension was not actually enabled and that -float-abi=hard didn’t work either.I wonder if there is some bug here?It’s worth saying that the old version of llc had no problems.

text
        .attribute      4, 16
        .attribute      5, "rv64i2p1"  // you can look there.
        .file   "LLVMDialectModule"
        .globl  main                            # -- Begin function main
        .p2align        2
        .type   main,@function

If anyone can help me, I would appreciate it.

2

D depends on F which depends on Zicsr (for FCSR, which contains FFLAGS and FRM); if you remove Zicsr then you remove anything that depends on it.

That error coming from GNU ld looks like you have some old broken version that doesn’t know how to parse multi-letter extensions.

3

Do you mean that the problem can only be solved by upgrading the version of gcc? Actually this problem is because I am using the latest llvm, is there a way to solve this problem here without changing the gcc version（Because the gcc version here is the gcc provided by other project）?

4

Your GNU linker is broken, so you need a non-broken GNU toolchain. AFAIK there is no way to turn off the generation of attributes for generated code.

5

I really appreciate you, you answered a lot of my questions. Here I have another question, here rv64i2p1_f2p2_d2p2_zicsr2p0 I can probably guess what it means, but is there any relevant documentation here to describe this kind of information, like here p, 0, 1, 2.

6

The RISC-V Instruction Set Manual Volume I: Unprivileged ISA, version 20191213 (the latest ratified version, available from https://riscv.org/technical/specifications/), chapter 27 “ISA Extension Naming Conventions”.

7

But, as a TL;DR, this is RV64I v2.1, F v2.2, D v2.2 and Zicsr v2.0.

8

Thank you!

9

I have made a new discovery on this problem.I have two files main.o and log.o(The deep learning model is stored inside, here is the resnet).By using llc to generate the corresponding assembly file, I found that there is "rv64i2p1_f2p2_d2p2_zicsr2p0", but if I delete "rv64i2p1_f2p2_d2p2_zicsr2p0" in main.s and then use gcc, gcc will not report the error.In fact, log.o still has "rv64i2p1_f2p2_d2p2_zicsr2p0", which is really strange, but actually main.s just calls the function in log.o.Another point is that if I make the function in log.o named main, there is actually no problem.I know this problem should not be related to llvm.

10

Yes, obviously hacking up the assembly to remove the attribute and using the other toolchain more can give you something that will link. But that’s not a solution, it’s a giant hack.

11

Your answer is very interesting and I will look for other ways to do it.Actually I found that log.o doesn’t affect the link even though it also has attributes that gcc can’t parse, I think it’s a bug in gcc. Because main.o actually comes from mlir, maybe I can eliminate this effect by writing c++ instead of mlir.

12

GNU ld, not GCC. GCC is just calling out to GNU ld. Writing C++ won’t help you, it’ll still go through the exact same LLVM backend. Unless of course you just use GCC to build your code.

Really you should just use a non-broken linker, whether that’s a newer GNU ld or LLVM’s own LLD. Anything else is just going to be a workaround that comes with compromise.

13

In fact, today I tried using the latest riscv-gnu-toolchain and although it solved the problem, it created a new problem I couldn’t solve, I couldn’t run the code on spike, spike says bad syscall, here spike is specifically extended and I can’t change its version.

14

You probably need the new compiler and linker with the old sysroot. Things like riscv-gnu-toolchain often have a nasty habit of combining toolchain and libc (and C runtime files), despite them being logically totally independent; the toolchain should really just be the toolchain, not toolchain+sysroot, which is what you seem to have.

Or you can just -fuse-ld=lld and ignore the toolchain part entirely, only using it for its libc.

1 Like
15

I think you are really knowledgeable and thank you for guidance!