Pourquoi les compilateurs C ++ n'optimisent-ils pas cette affectation booléenne conditionnelle comme une affectation inconditionnelle?

Considérez la fonction suivante:

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

Il me semble que si l'indicateur a une valeur booléenne valide, cela équivaudrait à le définir inconditionnellement true, comme ceci:

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

Pourtant, ni gcc ni clang ne l'optimisent de cette façon - les deux génèrent les éléments suivants au -O3niveau de l'optimisation:

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

Ma question est la suivante: est-ce simplement que le code est trop spécial pour être optimisé, ou y a-t-il de bonnes raisons pour lesquelles une telle optimisation serait indésirable, étant donné qu'il flagne s'agit pas d'une référence volatile? Il semble que la seule raison qui pourrait être est que cela flagpourrait d'une manière ou d'une autre avoir une valeur non- trueou- falsesans comportement indéfini au moment de la lecture, mais je ne suis pas sûr que cela soit possible.

Cela peut avoir un impact négatif sur les performances du programme en raison de considérations de cohérence du cache . Ecrire à flagchaque fois func()est appelé salirait la ligne de cache contenant. Cela se produira indépendamment du fait que la valeur en cours d'écriture correspond exactement aux bits trouvés à l'adresse de destination avant l'écriture.

ÉDITER

hvd a fourni une autre bonne raison qui empêche une telle optimisation. C'est un argument plus convaincant contre l'optimisation proposée, car elle peut entraîner un comportement indéfini, alors que ma réponse (originale) ne traitait que des aspects de performance.

Après un peu plus de réflexion, je peux proposer un autre exemple pour lequel les compilateurs devraient être fortement interdits - à moins qu'ils ne puissent prouver que la transformation est sûre pour un contexte particulier - d'introduire l'écriture inconditionnelle. Considérez ce code:

const bool foo = true;

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

Avec une écriture inconditionnelle, func()cela déclenche définitivement un comportement indéfini (l'écriture dans la mémoire morte mettra fin au programme, même si l'effet de l'écriture serait autrement un no-op).

Outre la réponse de Léon sur les performances:

Supposons que flagc'est true. Supposons que deux threads appellent constamment func(flag). La fonction telle qu'elle est écrite, dans ce cas, ne stocke rien dans flag, donc cela doit être thread-safe. Deux threads accèdent à la même mémoire, mais uniquement pour la lire. Définir inconditionnellement flagsur truesignifie que deux threads différents écriront dans la même mémoire. Ce n'est pas sûr, c'est dangereux même si les données en cours d'écriture sont identiques aux données déjà présentes.

Je ne suis pas sûr du comportement de C ++ ici, mais en C, la mémoire peut changer car si la mémoire contient une valeur non nulle autre que 1, elle resterait inchangée avec la vérification, mais changée à 1 avec la vérification.

Mais comme je ne maîtrise pas très bien le C ++, je ne sais pas si cette situation est même possible.