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
Created attachment 4465 [details] Test case
Created attachment 4466 [details] Asm at -O2
Please attach: 1. Preprocessed C source 2. Bitcode Thanks
The attachments didn't go through first. I have attached the C file and the llvm generated asm file.
(In reply to comment #4) > 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
Created attachment 4468 [details] preprocessed test case
Created attachment 4469 [details] llvm bit code
Created attachment 4470 [details] asm \
Created attachment 4471 [details] Asm at -O2
Please see the attachments. Thanks, Rohit
looks like 2 separate bugs: optimization and codegen
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 #5, r15 mov.w #6, 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
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.
(In reply to comment #13) > 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
(In reply to comment #14) > 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. * http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-June/032349.html
Anton fixed my problem* and convinced me that it wasn't relevant to this ticket, so I'll stop hijacking this ticket now. * http://lists.ransford.org/pipermail/llvm-msp430/2010-June/000180.html