[LLVMdev] How to stop target from writing results back to memory in MSP430

Avinash Bole boleavinash at gmail.com
Wed May 20 02:57:54 PDT 2015


Hello!!

Im trying to write a C Backend using LLVM. I tried modifying the target
"MSP430" to suit my backend. My target Architecture doesnt have a STACK. so
i used "mem2reg" option using "OPT". Now Problem i have is..., the results
produced are being written back to memory.

Following example should illustrate the problem

*Intermediate file after MEM2REG pass:*

@.str = private unnamed_addr constant [9 x i8] c"%d %d %d\00", align 1

; Function Attrs: nounwind
define void @main() #0 {
  %1 = add nsw i32 2, 10
  %2 = add nsw i32 %1, 3
  %3 = sub nsw i32 3, 2
  %4 = sub nsw i32 %3, 5
  %5 = xor i32 4, 4
  %6 = xor i32 %5, %5
  %7 = or i32 5, %4
  %8 = and i32 %4, 2
  %9 = or i32 7, 2
  %10 = or i32 %8, %6
  %11 = and i32 %9, %10
  %12 = call i32 (i8*, ...)* @printf(i8* getelementptr inbounds ([9 x i8]*
@.str, i32 0, i32 0), i32 7, i32 %11, i32 %6)
  ret void
}

*Assembly file in my target:*

main:                                   ; @main
; BB#0:
        Mov REG[12],.L.str,4
        Mov 0(REG[1]), REG[12],4
        Mov 6(REG[1]), 0,4
        Mov 4(REG[1]), 0,4
        Mov 2(REG[1]), 7,4
        Call printf
         Nop
         Nop
        Return;
.Ltmp0:
        .size   main, .Ltmp0-main

        .type   .L.str, at object          ; @.str
        .section        .rodata.str1.1,"aMS", at progbits,1

.L.str:
        .asciz  "%d %d %d"
        .size   .L.str, 9


As you can see..., 0 is written to 6(REG[1]) in third line. here REG[1] is
my frame pointer register and the compiler is writing result to memory
location 6(REG[1]).

This would have been valid with a stack..,but since my target doesnt have a
stack, i need to keep the results in REGISTERS ONLY.

So...,please suggest me how to prevent writing the final results to memory

Regards,
Avinash
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150520/a50730e8/attachment.html>


More information about the llvm-dev mailing list