On Tue, 2023-04-18 at 19:21 +0800, Lulu Cheng wrote:
>
> 在 2023/4/18 下午5:27, Xi Ruoyao 写道:
> > On Mon, 2023-04-10 at 17:45 +0800, Lulu Cheng wrote:
> > > Sorry, it's my question. I still have some questions that I haven't
> > > understood, so I haven't replied to the email yet.:-(
> > I've verified the value of cfun->va_list_gpr_size with -fdump-tree-
> > stdarg and various testcases (including extracting aggregates and
> > floating-point values in the va list) and the result seems correct. And
> > gcc/testsuite/gcc.c-torture/execute/va-arg-*.c should provide a good
> > enough test coverage.
> >
> > Is there still something seemly problematic?
>
>
> I think there is no problem with the code modification, but I found that
> the $r12 register is stored whether or not this patch is added. I don't
> understand why.:-(
It has been stored before the change:
test:
.LFB0 = .
.cfi_startproc
addi.d $r3,$r3,-80
.cfi_def_cfa_offset 80
addi.d $r12,$r3,24
st.d $r5,$r3,24
st.d $r6,$r3,32
st.d $r7,$r3,40
st.d $r8,$r3,48
st.d $r9,$r3,56
st.d $r10,$r3,64
st.d $r11,$r3,72
st.d $r12,$r3,8 # <=====
add.w $r4,$r5,$r4
addi.d $r3,$r3,80
.cfi_def_cfa_offset 0
jr $r1
.cfi_endproc
AFAIK it's related to how the variable arguments are implemented in
general. The problem is when we expands __builtin_va_list or
__builtin_va_arg, the registers containing the variable arguments and
the pointer to the variable argument store area (r12 in this case) may
be already clobbered, so the compiler have to store them expanding the
prologue of the function (when the prologue is expanded we don't know if
the following code will clobber the registers).
This also causes a difficulty to avoid saving the GARs for *used*
variable arguments as well.
On x86_64 we have the same issue:
test:
.LFB0:
.cfi_startproc
leaq 8(%rsp), %rax
movq %rsi, -40(%rsp)
movq %rax, -64(%rsp) # <=====
leaq -48(%rsp), %rax
movq %rax, -56(%rsp)
movl -40(%rsp), %eax
movl $8, -72(%rsp)
addl %edi, %eax
ret
.cfi_endproc
I'll try to remove all of these in the GCC 14 development cycle (as they
are causing sub-optimal code in various Glibc functions), but it's not
easy...
--
Xi Ruoyao <xry...@xry111.site>
School of Aerospace Science and Technology, Xidian University
