msp430 backend: arguments passed in wrong registers

[Quuxplusone]

Bugzilla Link	PR6573
Status	NEW
Importance	P normal
Reported by	Rohit Pagariya (pagariya@cs.utah.edu)
Reported on	2010-03-10 12:34:00 -0800
Last modified on	2010-06-21 15:20:21 -0700
Version	trunk
Hardware	PC Linux
CC	anton@korobeynikov.info, llvm-bugs@lists.llvm.org, ransford@cs.umass.edu, regehr@cs.utah.edu
Fixed by commit(s)
Attachments	test.c (192 bytes, text/x-csrc) test.s (373 bytes, application/octet-stream) preprocessed-test.c (169 bytes, text/x-csrc) test-llvm-ir.s (1016 bytes, application/octet-stream) test-asm.s (373 bytes, application/octet-stream) test-asm.s (373 bytes, application/octet-stream)
Blocks
Blocked by
See also

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

[Quuxplusone]

Please attach:

1. Preprocessed C source
2. Bitcode

Thanks

[Quuxplusone]

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

[Quuxplusone]

(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

[Quuxplusone]

Attached test.c (192 bytes, text/x-csrc): Test case

[Quuxplusone]

Attached preprocessed-test.c (169 bytes, text/x-csrc): preprocessed test case

[Quuxplusone]

Attached test-llvm-ir.s (1016 bytes, application/octet-stream): llvm bit code

[Quuxplusone]

Attached test.s (373 bytes, application/octet-stream): Asm at -O2

[Quuxplusone]

Attached test-asm.s (373 bytes, application/octet-stream): asm \

[Quuxplusone]

Attached test-asm.s (373 bytes, application/octet-stream): Asm at -O2

[Quuxplusone]

Please see the attachments.

Thanks,
Rohit

[Quuxplusone]

looks like 2 separate bugs: optimization and codegen

[Quuxplusone]

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

[Quuxplusone]

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.

[Quuxplusone]

(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

[Quuxplusone]

(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

[Quuxplusone]

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