[PATCH] D11249: Fix PR#24142

[Guozhi Wei via llvm-commits]

Carrot marked an inline comment as done.

================
Comment at: test/CodeGen/ARM/align-sp-adjustment.ll:4
@@ +3,3 @@
+; CHECK: [sp, #2120]
+
+%struct.struct_2 = type { [172 x %struct.struct_1] }
----------------
rnk wrote:
> Carrot wrote:
> > This number is the sum of stack frame and the space of outward parameter(8). The stack frame is:
> > 
> >         push.w  {r4, r5, r6, r7, r8, r9, r10, r11, lr} 
> > .Ltmp0:
> >         .cfi_def_cfa_offset 36
> > .Ltmp1:
> >         .cfi_offset lr, -4
> > .Ltmp2:
> >         .cfi_offset r11, -8
> > .Ltmp3:
> >         .cfi_offset r10, -12 
> > .Ltmp4:
> >         .cfi_offset r9, -16 
> > .Ltmp5:
> >         .cfi_offset r8, -20 
> > .Ltmp6:
> >         .cfi_offset r7, -24 
> > .Ltmp7:
> >         .cfi_offset r6, -28 
> > .Ltmp8:
> >         .cfi_offset r5, -32 
> > .Ltmp9:
> >         .cfi_offset r4, -36 
> >         .pad    #2064
> >         sub.w   sp, sp, #2064
> >         .pad    #12
> >         sub     sp, #12
> > 
> > 12 is padding, 2064 is the size of local variable, the rest are for callee saved registers. The only possible changing size is the space for callee saved registers, and the only possible optimization that can impact it is register allocation. There are several function call in the loop, most of the callee saved registers are used to keep variables cross function call, so this looks unlikely to change.
> I think you can reduce this test case further to make it more robust and easier to understand.
> 
> The string parameters are probably not needed, and can be i32's or i8* null values to make it shorter.
> 
> The array can instead be a simple array of i32, like `%params = alloca i32, 516`, which gives an i32*, which requires less GEP manipulation.
I tried to change the string to integer 0, unfortunately it failed to reproduce the bug. The reason is the compiler need to generate some instructions to compute the address of string, store it in some register, and moved the code out of the loop since it is loop invariant. If it is changed to some constant, then it need not to be stored in register, the extra register can be used store the value of the fifth parameter, the load is moved out of the loop, so avoid the problem code sequence. 

Similarly if I change the data type of %params, the address computation is also changed, and the register usage is changed, causes the fifth parameter loaded before the loop, and failed to reproduce the bug.



http://reviews.llvm.org/D11249