[LLVMdev] A question about Greedy Register Allocator's reload instruction.

[gcc2011]

Hi all, I'm very instresting in LLVM, and trying to port a dsp target on LLVM now.

I found that, the Greddy Register Allocator will generate a reload instrucion just between the function call and ADJCALLSTACKUP instruction. If the reload instruction is transfered to be a load instruction finally, which uses the SP register as an operand, and the target uses the ADJCALLSTACKUP instruction to adjust the SP register's value, will the reload instruction get a bad SP register value?

Let me use MBlaze to explain that:
compile option: clang -target mblaze -O2 -S -mllvm -unroll-threshold=1024 -mllvm -unroll-allow-partial demo.c -o demo.s -mllvm -print-after-all
The IR after Virtual Register Rewriter whill show this situation as below:
"
    BRLID R15, ga at printf, %R3<imp_def,dead>, %R4<imp_def,dead>, %R5<imp_def,dead>...
       %R4<def>=LWI <fi#5>,0
       ADJCALLSTACKUP 68, 0, %R1 <imp_def>, %R1<imp_def>
"
The instruction " %R4<def>=LWI <fi#5>,0" loads value from the stack, and it will use SP register as an operand. But the SP may need to be adjusted int the ADJCALLSTACKUP instruction(MBlaze will not do that), is it a problem? Or I get the wrong understanding? 

The demo code has no actual meaning.
demo.c:
extern float b[10][10];
extern void do_nothing(float a, float b);
void fun()
{
    register int i, j;
    register float f1, f2, f3, f4, f5, f6, f7, f8;
    float a[10][10];
    
    float(int i = 0; i < 10; i++)
    {
        float(int j = 0; j < 10; j++)
        {
            f1 = a[i][j];
            f2 = b[i][j];
            f3 = f1 + f2;
            f4 = f3 * f3;
            f5 = f4 - f3;
            f6 = f4 + f3;
            f7 = f5 + f6;
            f8 = f6 + f7;
            do_nothing(f1, f2);
        }
    }
    float(int i = 0; i < 10; i++)
    {
        float(int j = 0; j < 10; j++)
        {
            printf("%f %f %f %f %f %f %f %f \n", f3, f4, f5, f6, f7, f8, a[i][j], b[i][j]);
        }
    }
}

Thank you very much!

GooKe.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131117/9ad11277/attachment.html>