Hi Suwa-san, On Fri, Sep 2, 2022 at 3:57 AM Takayuki 'January June' Suwa <jjsuwa_sys3...@yahoo.co.jp> wrote: > > Changes from v1: > (xtensa_expand_epilogue): Fixed forgetting to consider > hard_frame_pointer_rtx when sharing codes. > > --- > In the example below, 'x' is once placed on the stack frame and then read > into registers as the argument value of bar(): > > /* example */ > struct foo { > int a, b; > }; > extern struct foo bar(struct foo); > struct foo test(void) { > struct foo x = { 0, 1 }; > return bar(x); > } > > Thanks to the dead store elimination, the initialization of 'x' turns into > merely loading the immediates to registers, but corresponding stack frame > growth is not rolled back. As a result: > > ;; prereq: the CALL0 ABI > ;; before > test: > addi sp, sp, -16 // unused stack frame allocation/freeing > movi.n a2, 0 > movi.n a3, 1 > addi sp, sp, 16 // because no instructions that refer to > j.l bar, a9 // the stack pointer between the two > > This patch eliminates such unused stack frame allocation/freeing: > > ;; after > test: > movi.n a2, 0 > movi.n a3, 1 > j.l bar, a9 > > gcc/ChangeLog: > > * config/xtensa/xtensa.cc (machine_function): New member to track > the insns for stack pointer adjustment inside of the pro/epilogue. > (xtensa_emit_adjust_stack_ptr): New function to share the common > codes and to record the insns for stack pointer adjustment. > (xtensa_expand_prologue): Change to use the function mentioned > above when using the CALL0 ABI. > (xtensa_expand_epilogue): Ditto. > And also change to cancel emitting the insns for the stack pointer > adjustment if only used for its own. > --- > gcc/config/xtensa/xtensa.cc | 230 ++++++++++++++++++------------------ > 1 file changed, 118 insertions(+), 112 deletions(-)
With this change xtensa-linux-uclibc configured for call0 ABI produces ICE while building libgcc: gcc/libgcc/libgcc2.c: In function ‘__divdi3’: gcc/libgcc/libgcc2.c:1230:1: internal compiler error: Segmentation fault 1230 | } | ^ 0xea801f crash_signal gcc/gcc/toplev.cc:314 0x7f1fb4be5d5f ??? ./signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0 0x9602e3 lookup_page_table_entry gcc/gcc/ggc-page.cc:630 0x9602e3 ggc_set_mark(void const*) gcc/gcc/ggc-page.cc:1550 0x121d7bd gt_ggc_mx_hash_set_rtx_insn__(void*) ./gt-xtensa.h:38 0xbe6187 gt_ggc_mx_function(void*) gcc-13-2434-g2f4d626e13dc-call0-le/gcc/gtype-desc.cc:1694 0xbe6187 gt_ggc_mx_function(void*) gcc-13-2434-g2f4d626e13dc-call0-le/gcc/gtype-desc.cc:1678 0x85634a gt_ggc_mx_lang_tree_node(void*) ./gt-c-c-decl.h:289 0xbe07d2 gt_ggc_mx_rtx_def(void*) gcc-13-2434-g2f4d626e13dc-call0-le/gcc/gtype-desc.cc:725 0xa47074 void gt_ggc_mx<dw_attr_struct>(vec<dw_attr_struct, va_gc, vl_embed>*) gcc/gcc/vec.h:1363 0xa47074 gt_ggc_mx_vec_dw_attr_node_va_gc_(void*) ./gt-dwarf2out.h:261 0xa47074 gt_ggc_mx_vec_dw_attr_node_va_gc_(void*) ./gt-dwarf2out.h:256 0xa47074 gt_ggc_mx_die_struct(void*) ./gt-dwarf2out.h:45 0xa470d7 gt_ggc_mx_die_struct(void*) ./gt-dwarf2out.h:27 0xa470d7 gt_ggc_mx_die_struct(void*) ./gt-dwarf2out.h:47 0xa470d7 gt_ggc_mx_die_struct(void*) ./gt-dwarf2out.h:27 0xa470d7 gt_ggc_mx_die_struct(void*) ./gt-dwarf2out.h:47 0xa470d7 gt_ggc_mx_die_struct(void*) ./gt-dwarf2out.h:27 0xa470d7 gt_ggc_mx_die_struct(void*) ./gt-dwarf2out.h:47 0xa470d7 gt_ggc_mx_die_struct(void*) ./gt-dwarf2out.h:27 -- Thanks. -- Max