¿Por qué los compiladores de C ++ no optimizan esta asignación booleana condicional como una asignación incondicional?

Considere la siguiente función:

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

Me parece que si la bandera tiene un valor booleano válido, esto sería equivalente a configurarlo incondicionalmente true, así:

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

Sin embargo, ni gcc ni clang lo optimizan de esta manera; ambos generan lo siguiente en el -O3nivel de optimización:

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

Mi pregunta es: ¿es solo que el código es un caso demasiado especial para preocuparse por optimizarlo, o hay buenas razones por las que dicha optimización no sería deseada, dado que flagno es una referencia a volatile? Parece que la única razón que podría ser es que de flagalguna manera podría tener un valor no true-o- falsesin un comportamiento indefinido en el momento de leerlo, pero no estoy seguro de si esto es posible.

Esto puede afectar negativamente al rendimiento del programa debido a consideraciones de coherencia de la caché . Escribir en flagcada vez que func()se llama ensuciaría la línea de caché que lo contiene. Esto sucederá independientemente del hecho de que el valor que se escribe coincide exactamente con los bits encontrados en la dirección de destino antes de la escritura.

EDITAR

hvd ha proporcionado otra buena razón que impide tal optimización. Es un argumento más convincente en contra de la optimización propuesta, ya que puede resultar en un comportamiento indefinido, mientras que mi respuesta (original) solo abordó aspectos de rendimiento.

Después de reflexionar un poco más, puedo proponer un ejemplo más de por qué los compiladores deberían estar estrictamente prohibidos, a menos que puedan demostrar que la transformación es segura para un contexto particular, de introducir la escritura incondicional. Considere este código:

const bool foo = true;

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

Con una escritura incondicional, func()esto definitivamente desencadena un comportamiento indefinido (escribir en la memoria de solo lectura terminará el programa, incluso si el efecto de la escritura sería, de lo contrario, no operativo).

Aparte de la respuesta de Leon sobre el rendimiento:

Suponer flag es true. Suponga que dos hilos están llamando constantemente func(flag). La función tal como está escrita, en ese caso, no almacena nada flag, por lo que debería ser seguro para subprocesos. Dos hilos acceden a la misma memoria, pero solo para leerla. Establecer incondicionalmente flaga truesignifica que dos subprocesos diferentes escribirían en la misma memoria. Esto no es seguro, no es seguro incluso si los datos que se escriben son idénticos a los datos que ya están allí.

No estoy seguro sobre el comportamiento de C ++ aquí, pero en C la memoria podría cambiar porque si la memoria contiene un valor distinto de cero que no sea 1, permanecería sin cambios con la verificación, pero cambiaría a 1 con la verificación.

Pero como no soy muy fluido en C ++, no sé si esta situación es posible.