Ruslan Ruslan - 6 months ago 31
C++ Question

Why don't C++ compilers optimize `if (!flag) flag = true` as `flag = true`?

Consider the following function:

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

It seems to me that if flag has a valid boolean value, this would be equivalent to unconditional setting it to
, like this:

void func(bool& flag)

Yet neither gcc nor clang optimize it this way — both generate the following at
optimization level:

cmp BYTE PTR [rdi], 0
jne .L1
mov BYTE PTR [rdi], 1
rep ret

My question is: is it just that the code is too special-case to care to optimize, or are there any good reasons why such optimization would be undesired, given that
is not a reference to
? It seems the only reason which might be is that
could somehow have a non-
value without undefined behavior at the point of reading it, but I'm not sure whether this is possible.


This may negatively impact the performance of the program due to cache coherence considerations. Writing to flag each time func() is called would dirty the containing cache line. This will happen regardless of the fact that the value being written exactly matches the bits found at the destination address before the write.


hvd has provided another good reason that prevents such an optimization. It is a more compelling argument against the proposed optimization, since it may result in undefined behavior, whereas my (original) answer only addressed performance aspects.

After a little more reflection, I can propose one more example why compilers should be strongly banned - unless they can prove that the transformation is safe for a particular context - from introducing the unconditional write. Consider this code:

const bool foo = true;

int main()

With an unconditional write in func() this definitely triggers undefined behavior (writing to read-only memory will terminate the program, even if the effect of the write would otherwise be a no-op).