Dlaczego kompilatory C ++ nie optymalizują tego warunkowego przypisania boolowskiego jako przypisania bezwarunkowego?

Rozważ następującą funkcję:

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

Wydaje mi się, że jeśli flaga ma prawidłową wartość logiczną, byłoby to równoważne z bezwarunkowym ustawieniem jej na true, na przykład:

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

Jednak ani gcc, ani clang nie optymalizują go w ten sposób - oba generują następujące informacje na -O3poziomie optymalizacji:

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

Moje pytanie brzmi: czy po prostu kod jest zbyt szczególny, aby go zoptymalizować, czy też istnieją dobre powody, dla których taka optymalizacja byłaby niepożądana, biorąc pod uwagę, że flagnie jest to odniesienie volatile? Wydaje się, że jedynym powodem, który może być, jest to, że flagmoże w jakiś sposób mieć wartość inną niż - truelub - falsebez niezdefiniowanego zachowania w momencie czytania, ale nie jestem pewien, czy jest to możliwe.

Może to negatywnie wpłynąć na wydajność programu ze względu na kwestie spójności pamięci podręcznej . Pisanie do flagkażdego func()wywołania spowodowałoby zanieczyszczenie zawierającej ją linii pamięci podręcznej. Stanie się tak niezależnie od tego, że zapisywana wartość dokładnie odpowiada bitom znalezionym pod adresem docelowym przed zapisem.

EDYTOWAĆ

hvd podało kolejny dobry powód, który uniemożliwia taką optymalizację. Jest to bardziej przekonujący argument przeciwko proponowanej optymalizacji, ponieważ może skutkować nieokreślonym zachowaniem, podczas gdy moja (oryginalna) odpowiedź dotyczyła tylko aspektów wydajności.

Po dłuższej refleksji mogę zaproponować jeszcze jeden przykład, dlaczego kompilatorom należy bezwzględnie zakazać - chyba że udowodnią, że transformacja jest bezpieczna w określonym kontekście - wprowadzania bezwarunkowego zapisu. Rozważ ten kod:

const bool foo = true;

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

Z bezwarunkowym zapisem w func()ten sposób zdecydowanie wyzwala niezdefiniowane zachowanie (zapis do pamięci tylko do odczytu zakończy program, nawet jeśli w przeciwnym razie efekt zapisu byłby bez operacji).

Oprócz odpowiedzi Leona na temat wydajności:

Przypuśćmy, że flagtak true. Załóżmy, że dwa wątki ciągle dzwonią func(flag). Zapisana funkcja w tym przypadku nic nie przechowuje flag, więc powinna być bezpieczna dla wątków. Dwa wątki mają dostęp do tej samej pamięci, ale tylko w celu jej odczytu. Bezwarunkowe ustawienie flagna trueoznacza, że ​​dwa różne wątki będą zapisywać w tej samej pamięci. To nie jest bezpieczne, jest to niebezpieczne, nawet jeśli zapisywane dane są identyczne z danymi, które już tam są.

Nie jestem pewien co do zachowania C ++ tutaj, ale w C pamięć może się zmienić, ponieważ jeśli pamięć zawiera niezerową wartość inną niż 1, pozostałaby niezmieniona podczas sprawdzania, ale zmieniłaby się na 1 podczas sprawdzania.

Ale ponieważ nie jestem biegły w C ++, nie wiem, czy taka sytuacja jest w ogóle możliwa.