Perché i compilatori C ++ non ottimizzano questa assegnazione booleana condizionale come assegnazione incondizionata?

Considera la seguente funzione:

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

Mi sembra che se flag ha un valore booleano valido, questo sarebbe equivalente all'impostazione incondizionata su true, in questo modo:

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

Tuttavia, né gcc né clang lo ottimizzano in questo modo, entrambi generano quanto segue a -O3livello di ottimizzazione:

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

La mia domanda è: è solo che il codice è troppo speciale per preoccuparsi di ottimizzarlo, o ci sono buone ragioni per cui tale ottimizzazione sarebbe indesiderata, dato che flagnon è un riferimento volatile? Sembra che l'unica ragione che potrebbe essere è che flagpotesse in qualche modo avere un non- trueoppure falsevalore senza un comportamento indefinito in corrispondenza del punto di leggerlo, ma non sono sicuro se questo è possibile.

Ciò potrebbe influire negativamente sulle prestazioni del programma a causa di considerazioni sulla coerenza della cache . Scrivere flagogni volta che func()viene chiamato sporcherebbe la riga della cache che lo contiene. Ciò avverrà indipendentemente dal fatto che il valore che viene scritto corrisponda esattamente ai bit trovati all'indirizzo di destinazione prima della scrittura.

MODIFICARE

hvd ha fornito un altro buon motivo che impedisce tale ottimizzazione. È un argomento più convincente contro l'ottimizzazione proposta, poiché potrebbe comportare un comportamento indefinito, mentre la mia risposta (originale) ha affrontato solo gli aspetti delle prestazioni.

Dopo un po 'più di riflessione, posso proporre un altro esempio del motivo per cui i compilatori dovrebbero essere fortemente vietati - a meno che non possano dimostrare che la trasformazione è sicura per un particolare contesto - dall'introduzione della scrittura incondizionata. Considera questo codice:

const bool foo = true;

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

Con una scrittura incondizionata in func()questo si innesca sicuramente un comportamento indefinito (la scrittura nella memoria di sola lettura terminerà il programma, anche se l'effetto della scrittura sarebbe altrimenti un no-op).

A parte la risposta di Leon sulle prestazioni:

Supponiamo che flagsia true. Supponiamo che due thread chiamino costantemente func(flag). La funzione come scritta, in tal caso, non memorizza nulla in flag, quindi dovrebbe essere thread-safe. Due thread accedono alla stessa memoria, ma solo per leggerla. L'impostazione incondizionatamente flagsu truesignifica che due thread diversi scriveranno nella stessa memoria. Questo non è sicuro, non è sicuro anche se i dati scritti sono identici ai dati già presenti.

Non sono sicuro del comportamento di C ++ qui, ma in C la memoria potrebbe cambiare perché se la memoria contiene un valore diverso da zero diverso da 1, rimarrebbe invariato con il controllo, ma cambiato in 1 con il controllo.

Ma poiché non sono molto fluente in C ++, non so se questa situazione sia possibile.