Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Calling Convention not respected #32

Open
federeghe opened this issue Jul 8, 2016 · 7 comments
Open

Calling Convention not respected #32

federeghe opened this issue Jul 8, 2016 · 7 comments

Comments

@federeghe
Copy link

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

@federeghe federeghe changed the title Wrong jump generation Wrong jump generation with -O1 Jul 8, 2016
@sorear
Copy link

sorear commented Jul 8, 2016

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

@federeghe
Copy link
Author

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
Copy link

sorear commented Jul 16, 2016

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 federeghe changed the title Wrong jump generation with -O1 Calling Convention not respected Aug 4, 2016
@federeghe
Copy link
Author

I think it is the last calling convention of RISCV implemented in f4c04ee. 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
Copy link

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
Copy link

sorear commented Jan 9, 2017

Note, this repository does not have an active maintainer.

@hirooih
Copy link

hirooih commented Mar 6, 2017

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...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants