Início / coding / Perguntas / 78952274
Accepted
einpoklum
Asked: 2024-09-05 17:27:02 +0800 CST

É suficiente restringir apenas os parâmetros "out" (ponteiro) de uma função?

  • 772

Suponha que eu tenha uma função que recebe alguns parâmetros de ponteiro - alguns não-const, através dos quais ela pode escrever, e alguns const através dos quais ela apenas lê. Exemplo:

void f(int * a, int const *b);

Suponha também que a função não escreva na memória (ou seja, não use variáveis ​​globais, endereços fixos, reformule os ponteiros const como não-const e truques do tipo).

Agora, é suficiente (de acordo com o padrão da linguagem C), para atingir os benefícios de restricttodas as leituras dentro de f(), apenas restrictos parâmetros de saída? Ou seja, no exemplo, restringir, amas não b?

Um teste simples (GodBolt) sugere que tal restrição deve ser suficiente. Esta fonte:

int f(int * restrict a, int const * b) {
    a[0] += b[0];
    return a[0] + b[0];
}

int all_restricted(int * restrict a, int const * restrict b) {
    a[0] += b[0];
    return a[0] + b[0];
}

int unrestricted(int * a, int const * b) {
    a[0] += b[0];
    return a[0] + b[0];
}

Produz o mesmo código objeto para x86_64:

f:
        mov     eax, DWORD PTR [rsi]
        mov     edx, DWORD PTR [rdi]
        add     edx, eax
        mov     DWORD PTR [rdi], edx
        add     eax, edx
        ret
all_restricted:
        mov     eax, DWORD PTR [rsi]
        mov     edx, DWORD PTR [rdi]
        add     edx, eax
        mov     DWORD PTR [rdi], edx
        add     eax, edx
        ret
unrestricted:
        mov     eax, DWORD PTR [rsi]
        add     eax, DWORD PTR [rdi]
        mov     DWORD PTR [rdi], eax
        add     eax, DWORD PTR [rsi]
        ret

mas isso não é uma garantia geral.

c

3 respostas

  1. Best Answer

    Não, não é suficiente.

    Suponha também que a função não escreva na memória (ou seja, não use variáveis ​​globais, endereços fixos, reformule os ponteiros const como não-const e truques do tipo).

    Esta suposição é insuficiente. Também seria necessário que o compilador veja que a função não escreve de outra forma na memória para a qual o ponteiro aponta (incluindo qualquer memória que poderia ser acessada via ponteiro, como b[18]). Por exemplo, se o chama bar(b);, e o compilador não pode ver bar, então ele não pode saber se a memória para a qual baponta é modificada durante a execução de f, mesmo que não seja.

    Dê esta premissa adicional, que o compilador pode ver que não há modificações em nenhuma memória apontada via b, então não importa para otimização se bé declarado com conste/ou restrict: O compilador sabe tudo sobre a memória, e dizer mais alguma coisa não acrescenta informação.

    Entretanto, muitas vezes não é o caso de o código satisfazer essa premissa. (E mesmo quando isso acontece, pode ser um incômodo para um programador ter certeza disso.) Então, vamos considerar um caso em que não temos a premissa adicional:

    void f(int * restrict a, int const *b)
{
    printf("%d\n", *b);
    bar();
    printf("%d\n", *b);
}

    Quando baré chamado, o compilador não sabe se *bé modificado. Mesmo que esta função não passe bpara bar, barpode acessar algum objeto externo que é *bou tem um ponteiro para onde *bé, e assim barpode alterar o objeto que é *b. Portanto, o compilador deve recarregar *bda memória para o segundo printf.

    Se, em vez disso, declararmos a função void f(int * restrict a, int const * restrict b), então restrictafirma que, se *bfor modificado durante a execução de f(incluindo indiretamente, dentro de bar), então todo acesso a ele será via b(diretamente, como em *b, ou indiretamente, como através de um ponteiro visivelmente copiado ou calculado de b). Como o compilador pode ver barque não recebe b, ele sabe barque não contém nenhum acesso a *bque seja baseado em b, e, portanto, pode assumir barque não altera *b.

    Portanto, adicionar restrictum parâmetro que é um ponteiro para um consttipo qualificado pode permitir algumas otimizações, mesmo que todos os outros parâmetros também sejam declarados restrict.

    • 6

  2. A constpalavra-chave como mostrada causará um aviso ou erro se você tentar modificar o valor apontado pelo ponteiro, mas não necessariamente impedirá que você modifique esse valor, e certamente não impedirá que outra pessoa modifique esse valor. Assim, o compilador pode ter que assumir que tais modificações podem ocorrer.

    Por exemplo, se você invocar alguma função definida em um arquivo de origem diferente, o compilador não terá conhecimento do que essa função faz, então ele terá que assumir que a função pode, de alguma forma, ter acesso ao valor apontado por esse ponteiro e pode modificá-lo.

    Além disso, mesmo que você modifique o valor apontado pelo ponteiro não constante, esse ponteiro não constante pode estar apontando para o mesmo valor que o ponteiro constante. (Como em, f( &x, &x );) Sem restricto ponteiro constante, o compilador tem que assumir que isso também é uma possibilidade.

    Portanto, até mesmo o constparâmetro poderia se beneficiar da restrictpalavra-chave, porque ela promete que a memória apontada por esse ponteiro não será modificada por ninguém. Essencialmente, você estaria prometendo que nunca faria algo como f( &x, &x );.

    • 1

  3. Suponha que eu tenha uma função que recebe alguns parâmetros de ponteiro - alguns não-const, através dos quais ela pode escrever, e alguns const através dos quais ela apenas lê. Exemplo:

    void f(int * a, int const *b);

    Suponha também que a função não escreva na memória (ou seja, não use variáveis ​​globais, endereços fixos, reformule os ponteiros const como não-const e truques do tipo).

    Agora, é suficiente (de acordo com o padrão da linguagem C), para atingir os benefícios de restricttodas as leituras dentro de f(), apenas restrict os parâmetros de saída? Ou seja, no exemplo, restringir, amas não b?

    restricté unilateral. Ele licencia o compilador para fazer suposições sobre acessos de objetos via lvalues ​​"com base" no restrictponteiro -qualificado que não depende se algum outro ponteiro também é restrict-qualificado.

    Em particular, se você restrictparametrizar aentão, independentemente de você também restrict parametrizar b, você licencia o compilador para assumir que durante qualquer execução de f(),

    • se Lfor qualquer lvalue cujo endereço é "baseado em" ae
    • Lé usado para acessar o objeto que ele designa (leitura ou gravação) e
    • esse objeto é modificado por qualquer meio durante a execução da função, então
    • todo acesso a esse objeto (leitura ou escrita) durante a execução dessa função será realizado por meio de um lvalue cujo endereço é "baseado em" a, embora não necessariamente via Lem particular.
    • (Por exemplo, esse objeto não será acessado por meio de um lvalue "based on", bmas não em a.)

    Isso é explicado com mais detalhes na seção 6.7.3.1 do C17, embora esse texto seja complexo e um pouco carregado.

    Assim, no caso que você descreve, restricting apenas aautoriza o compilador a assumir que leituras via ponteiros derivados de bnunca observarão gravações via ponteiros derivados de a. Se ele realmente gerará código diferente é uma questão totalmente diferente, é claro.

    • 1

relate perguntas