[llvm-commits] [ARM] Fix for blocking PR13790. AAPCS byval params issue.
manman ren
mren at apple.com
Fri Oct 12 12:23:54 PDT 2012
On Oct 12, 2012, at 12:05 PM, Stepan Dyatkovskiy <stpworld at narod.ru> wrote:
> Hi Manman,
>
>
> > Why do we still need to store r1? I thought after the fix, only r2 and r3 are used :]
> >
> > +; CHECK: stm r0, {r1, r2, r3}
> > + %g = alloca i8*
> > + %g1 = bitcast i8** %g to i8*
> > + call void @llvm.va_start(i8* %g1)
>
> Initially I had the same thoughts, but test_byval_8_bytes_alignment is VA function, so it knows nothing about parameters VA args alignment
> define void @test_byval_8_bytes_alignment(i32 %i, ...)
>
> In prolog we should store all possible regs into 8 bytes aligned area (stack has 8 bytes alignment). The 4 byte padding is added at the beginning. Finally for byval regs we have 16 bytes area in stack:
>
> AREA_START:
> [ i32 undef, i32 r1, i32 r2, i32 r3 ]
>
> But when you invoke va_arg for double, you know that this param has 8 bytes alignment, and you know address where first register is stored:
>
> VA_ARG_DOUBLE = AREA_START + #4.
>
> Then since align == 8, rounding up is performed for VA_ARG_DOUBLE. So after all you got:
>
> VA_ARG_DOUBLE = AREA_START + #4 + #4
>
> It is address of r2.
Thanks for the explanation, that makes sense.
Could you try to add a testing case using byval as a fixed argument :]
Manman
>
> The next lines checks this behaviour:
> +; CHECK: add [[REG:(r[0-9]+)|(lr)]], {{(r[0-9]+)|(lr)}}, #7
> +; CHECK: bfc [[REG]], #0, #3
>
> Imho itsa nice trick :-)
>
> -Stepan.
>
More information about the llvm-commits
mailing list