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

msp430 backend: arguments passed in wrong registers #6945

Open
llvmbot opened this issue Mar 10, 2010 · 15 comments
Open

msp430 backend: arguments passed in wrong registers #6945

llvmbot opened this issue Mar 10, 2010 · 15 comments
Labels
backend:MSP430 bugzilla Issues migrated from bugzilla miscompilation

Comments

@llvmbot
Copy link
Collaborator

llvmbot commented Mar 10, 2010

Bugzilla Link 6573
Version trunk
OS Linux
Attachments Test case, Asm at -O2
Reporter LLVM Bugzilla Contributor
CC @asl,@regehr

Extended Description

Test case:

#include <stdint.h>

int8_t g_8[6][10];

int main(void)
{
int i, j;
for (i = 0; i < 6; i++)
{
for (j = 0; j < 10; j++)
g_8[i][j] = 0x44L;
}
return 0;
}

Description:
In the above code g_8 is an array of 6x10 bytes, which is initialized to 0x44. At -O2 and -O3, this array is initialized using memset().

C interface to memset(): void* memset(void* ptr, int value, size_t num);
Asm interface to memset(): ptr -> reg r15
data -> reg r14
size -> reg r13

Assembly code at -O2 and -O3 for call to memset():

main:
mov.w #​0, r11
.LBB1_1
mov.w r11, r15
add.w #g_8, r15
mov.w #​68, r14
mov.w #​0, r13 /* size expected here, passed 0 /
mov.w #​10, r12 /
Size passed in r12, ignored */
call #memset
add.w #​10, r11
cmp.w #​60, r11
jne .LBB1_1
mov.w #​0, r15

Bug: size argument to memset() should be passed in register r13. Instead it is passed in r12.

I am attaching the asm file at -O2. Below are the cmdline options.

pagariya@aleph:~/randprog-testing/main/tmp$ clang -ccc-host-triple msp430-elf -I/home/pagariya/res-pagariya/llvm-msp430/msp430/include -nostdinc -v -O2 -S test.c
clang version 1.1 (trunk 184)
Target: msp430-elf-
Thread model: posix
"/uusoc/facility/res/embed/users/pagariya/llvm-msp430/bin/clang" -cc1 -triple msp430-elf- -S -disable-free -main-file-name test.c -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -v -nostdinc -resource-dir /uusoc/facility/res/embed/users/pagariya/llvm-msp430/lib/clang/1.1 -I/home/pagariya/res-pagariya/llvm-msp430/msp430/include -O2 -fmessage-length 102 -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o test.s -x c test.c
clang -cc1 version 1.1 based upon llvm 2.7svn hosted on i386-pc-linux-gnu
#include "..." search starts here:
#include <...> search starts here:
/home/pagariya/res-pagariya/llvm-msp430/msp430/include
/uusoc/facility/res/embed/users/pagariya/llvm-msp430/lib/clang/1.1/include
End of search list.

pagariya@aleph:~/randprog-testing/main/tmp$ uname -a
Linux aleph 2.6.24-24-generic #​1 SMP Fri Sep 18 16:49:39 UTC 2009 i686 GNU/Linux

@asl
Copy link
Collaborator

asl commented Mar 10, 2010

Please attach:

  1. Preprocessed C source
  2. Bitcode

Thanks

@llvmbot
Copy link
Collaborator Author

llvmbot commented Mar 10, 2010

The attachments didn't go through first. I have attached the C file and the llvm
generated asm file.

@asl
Copy link
Collaborator

asl commented Mar 10, 2010

The attachments didn't go through first. I have attached the C file and the
llvm
generated asm file.
They are obviously useless to reproduce the problem

@llvmbot
Copy link
Collaborator Author

llvmbot commented Mar 10, 2010

preprocessed test case

@llvmbot
Copy link
Collaborator Author

llvmbot commented Mar 10, 2010

llvm bit code

@llvmbot
Copy link
Collaborator Author

llvmbot commented Mar 10, 2010

asm

@llvmbot
Copy link
Collaborator Author

llvmbot commented Mar 10, 2010

Asm at -O2

@llvmbot
Copy link
Collaborator Author

llvmbot commented Mar 10, 2010

Please see the attachments.

Thanks,
Rohit

@asl
Copy link
Collaborator

asl commented Mar 11, 2010

looks like 2 separate bugs: optimization and codegen

@llvmbot
Copy link
Collaborator Author

llvmbot commented Jun 11, 2010

As far as I can tell, arguments aren't being passed at all now. Here's a simple program to add two numbers together:

int add(int a, int b) { return a+b; }
int main (void) { return add(5, 6); }

llc from March 16th produces this correct code to call add(a,b):

mov.w	llvm/llvm-project#377, r15
mov.w	llvm/llvm-project#378, r14
call	#add

llc from a few minutes ago produces this incorrect code for the same call:

; no movs to r14,r15! 
call	#add

-ben

@llvmbot
Copy link
Collaborator Author

llvmbot commented Jun 11, 2010

I did a little old-fashioned binary search between a known-broken revision number and a known-OK revision number; it seems that r98938 (http://llvm.org/viewvc/llvm-project?view=rev&revision=98938) broke this. On inspection I have no idea why, so I'll ask llvmdev.

@llvmbot
Copy link
Collaborator Author

llvmbot commented Jun 11, 2010

I did a little old-fashioned binary search between a known-broken revision
number and a known-OK revision number; it seems that r98938
(http://llvm.org/viewvc/llvm-project?view=rev&revision=98938) broke this. On
inspection I have no idea why, so I'll ask llvmdev.

Specifically, this one little change causes MSP430 argument passing to break:
http://llvm.org/viewvc/llvm-project/llvm/trunk/utils/TableGen/DAGISelMatcherGen.cpp?r1=98938&r2=98937&pathrev=98938

@llvmbot
Copy link
Collaborator Author

llvmbot commented Jun 21, 2010

Specifically, this one little change causes MSP430 argument passing to break:
http://llvm.org/viewvc/llvm-project/llvm/trunk/utils/TableGen/DAGISelMatcherGen.cpp?r1=98938&r2=98937&pathrev=98938

I gave up my search for a solution after slogging through some .td files and not understanding them well enough. Nobody responded to my llvmdev query*, so I assume there are too few embedded-software people on that list to care. I reversed r98938 in my mirror of the LLVM repo, so this problem isn't especially acute for me at the moment.

@llvmbot
Copy link
Collaborator Author

llvmbot commented Jun 21, 2010

Anton fixed my problem* and convinced me that it wasn't relevant to this ticket, so I'll stop hijacking this ticket now.

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 3, 2021
Michael137 pushed a commit to Michael137/llvm-project that referenced this issue Jun 2, 2023
[index] NFC: Add a symbol kind for init accessor
@llvmbot
Copy link
Collaborator Author

llvmbot commented Aug 9, 2023

@llvm/issue-subscribers-backend-msp430

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backend:MSP430 bugzilla Issues migrated from bugzilla miscompilation
Projects
None yet
Development

No branches or pull requests

3 participants