Por que os compiladores C ++ não otimizam essa atribuição booleana condicional como uma atribuição incondicional?

Considere a seguinte função:

void func(bool& flag)
{
    if(!flag) flag=true;
}

Parece-me que se o sinalizador tiver um valor booleano válido, isso seria equivalente a defini-lo truecomo incondicional , assim:

void func(bool& flag)
{
    flag=true;
}

No entanto, nem o gcc nem o clang o otimizam dessa maneira - ambos geram o seguinte no -O3nível de otimização:

_Z4funcRb:
.LFB0:
    .cfi_startproc
    cmp BYTE PTR [rdi], 0
    jne .L1
    mov BYTE PTR [rdi], 1
.L1:
    rep ret

Minha pergunta é: é apenas que o código é muito especial para cuidar de otimizar, ou há algum bom motivo para tal otimização ser indesejada, visto que flagnão é uma referência volatile? Parece que a única razão que pode ser é que flagpoderia, de alguma forma, ter um não- trueou- falsevalor sem comportamento indefinido no momento da leitura, mas não tenho certeza se isso é possível.

Isso pode impactar negativamente o desempenho do programa devido a considerações de coerência do cache . Escrever para flagcada vez que func()for chamado sujaria a linha de cache que o contém. Isso acontecerá independentemente do fato de que o valor que está sendo escrito corresponde exatamente aos bits encontrados no endereço de destino antes da escrita.

EDITAR

hvd forneceu outra boa razão que impede essa otimização. É um argumento mais convincente contra a otimização proposta, uma vez que pode resultar em um comportamento indefinido, enquanto minha resposta (original) abordava apenas aspectos de desempenho.

Após um pouco mais de reflexão, posso propor mais um exemplo de por que os compiladores devem ser fortemente proibidos - a menos que eles possam provar que a transformação é segura para um contexto particular - de introduzir a gravação incondicional. Considere este código:

const bool foo = true;

int main()
{
    func(const_cast<bool&>(foo));
}

Com uma gravação incondicional, func()isso definitivamente aciona um comportamento indefinido (gravar na memória somente leitura encerrará o programa, mesmo se o efeito da gravação for de outra forma um no-op).

Além da resposta de Leon sobre o desempenho:

Suponha que flagé true. Suponha que dois threads estejam constantemente chamando func(flag). A função conforme escrita, nesse caso, não armazena nada em flag, portanto, deve ser thread-safe. Dois threads acessam a mesma memória, mas apenas para lê-la. Definido incondicionalmente flagcomo truesignifica que dois threads diferentes estariam gravando na mesma memória. Isso não é seguro, isso não é seguro, mesmo se os dados que estão sendo gravados forem idênticos aos dados que já estão lá.

Não tenho certeza sobre o comportamento de C ++ aqui, mas em C a memória pode mudar porque se a memória contiver um valor diferente de zero diferente de 1, ela permaneceria inalterada com a verificação, mas mudaria para 1 com a verificação.

Mas como não sou muito fluente em C ++, não sei se essa situação é possível.