Início / coding / Perguntas / 79560492
Accepted
EnzoR
Asked: 2025-04-08 01:40:43 +0800 CST

Por que o RISC-V gcc cria instruções inúteis para reservar espaço de pilha em uma função que retorna uma struct?

  • 772

Esta fonte C:

typedef struct {
  unsigned long one;
  unsigned long two;
} twin;

twin function( twin t ) {
  return (twin){ 0,0 };
}

gera esta montagem:

        .file   "p.c"
        .option nopic
        .attribute arch, "rv64i2p1_m2p0_a2p1_f2p2_d2p2_c2p0_zicsr2p0_zifencei2p0"
        .attribute unaligned_access, 0
        .attribute stack_align, 16
        .text
        .align  1
        .globl  function
        .type   function, @function
function:
        addi    sp,sp,-32  # <<< WHY?
        li      a0,0
        li      a1,0
        addi    sp,sp,32   # <<< WHY?
        jr      ra
        .size   function, .-function
        .ident  "GCC: (g04696df09) 14.2.0"
        .section        .note.GNU-stack,"",@progbits

quando executado riscv64-unknown-elf-gcc (g04696df09) 14.2.0com ou -O3ou -O2ou -O1mesmo -Os.

Então por que o código está criando espaço na pilha para coisas (32 bytes) que são e serão mantidas em registradores a0e a1?

Isso é um bug ou estou esquecendo de alguma coisa?

assembly

1 respostas

  1. Best Answer

    Sim, parece um bug de otimização perdida que você pode relatar no Bugzilla do GCC. https://gcc.gnu.org/bugzilla

    Ele faz a mesma coisa visando o Linux com RV32 GCC ( Godbolt ), mesmo com -fomit-frame-pointer. As instruções de ponteiro de pilha desperdiçadas estão presentes com GCC8 (o mais antigo em Godbolt) através do trunk.

    Estou bastante confiante de que nenhuma ABI exige isso, e o Clang não os emite.

    # Clang -O2 or -Os for RV64, same for RV32 where unsigned long is only 32 bits
test1:
        or      a2, a1, a0
        xor     a1, a1, a0
        mv      a0, a2
        ret

    Uma mvé inevitável, pois precisamos substituir ambos a0e a1por valores que dependem de ambas as entradas originais. Portanto, não podemos sobrescrever nem a0ou a1com a primeira instrução. Mas certamente não precisa derramar nada, e é uma função folha, então salvar o endereço de retorno não é necessário. E não estamos usando um ponteiro de quadro, então salvar o FP do chamador também não é necessário.

    O ingrediente-chave para reproduzir isso é uma struct local; isso não acontece com, int r = u1^u2;por exemplo. Então, talvez o GCC não esteja conseguindo otimizar o espaço de pilha para essa struct, que ele otimiza em registradores. ret r = { 0, 0 };Ainda a reproduz.

    • 3

relate perguntas