ucb-bar / esp-llvm

UCB-BAR fork of LLVM! NOT UPSTREAM RISCV LLVM
Other
123 stars 55 forks source link

Calling Convention not respected #32

Open federeghe opened 8 years ago

federeghe commented 8 years ago

Hi! I think there is a problem in riscv-trunk when compiled with -O1 option. I attached an example in c and the generated assembly.

I compile with:

/.../clang -O1 -target riscv -mriscv=RV32I test.c -S -o test.S /.../riscv32-unknown-elf-gcc test.S -o test.o

I think that the last jalr (line 42) jumps to a wrong address.

test.zip

sorear commented 8 years ago

How so? That's your last printf call, and it's targetting printf; compute doesn't clobber x12

federeghe commented 8 years ago

Is it possible that x12 is overwritten by the printf itself? The address in x12 is calculated before the first printf, but it isn't recalculated before the subsequent call to printf, so x12 may contain invalid address if printf uses it.

sorear commented 8 years ago

You're probably right yeah. If x12 is caller-saved, then main is failing to save it around the printf, and if it's callee-saved, then main is failing to save it. Not sure which version of the calling convention LLVM presently implements.

federeghe commented 8 years ago

I think it is the last calling convention of RISCV implemented in f4c04eec45a3cf50fd709435cea60ab58c5b95e9. In fact, x12 is caller-saved but it seems that the backend interprets it as callee-saved.

I'm trying to figure out where is the error in the code, but I'm not an expert of LLVM, so it's quite difficult.

sapostolakis commented 7 years ago

I had the same problem.
I found a commit (ce8ac4e) in a different branch (caller-saved-fix) that seems to fix the bug that you and I had. Not sure why the additional spill slots were added (lib/Target/RISCV/RISCVFrameLowering.cpp) but the rest makes sense.

I don't know also why this branch (caller-saved-fix) was not merged with the riscv-trunk branch.

sorear commented 7 years ago

Note, this repository does not have an active maintainer.

hirooih commented 7 years ago

I came here to find a solution for a bug which I found on dhrystone.

...
    94    strcpy (Ptr_Glob->variant.var_1.Str_Comp, 
    95            "DHRYSTONE PROGRAM, SOME STRING");
    96    strcpy (Str_1_Loc, "DHRYSTONE PROGRAM, 1'ST STRING");
...

This lines were compiled to; (strcpy(dst, src) is converted to memcpy(dst, src, size))

...
204000e2:       20404337                lui     t1,0x20404
204000e6:       7f030593                addi    a1,t1,2032 # 204047f0 <__clzsi2+0x66>
204000ea:       01028513                addi    a0,t0,16
204000ee:       467d                    li      a2,31 // the 3rd arg, size
204000f0:       386010ef                jal     ra,20401476 <memcpy> // a2 is overwritten by the callee
204000f4:       204052b7                lui     t0,0x20405
204000f8:       80f28593                addi    a1,t0,-2033 # 2040480f <__clzsi2+0x85>
204000fc:       06c40513                addi    a0,s0,108

20400100 <Ltmp15>:
20400100:       376010ef                jal     ra,20401476 <memcpy> // a2 should be 31
...

The commit (ce8ac4e) fixed this issue.

Note, this repository does not have an active maintainer.

This is a bad news...