Ruslan Ruslan - 1 month ago 10
C++ Question

Why don't C++ compilers optimize this conditional boolean assignment as an unconditional assignment?

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
true
, like this:

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


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

_Z4funcRb:
.LFB0:
.cfi_startproc
cmp BYTE PTR [rdi], 0
jne .L1
mov BYTE PTR [rdi], 1
.L1:
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
flag
is not a reference to
volatile
? It seems the only reason which might be is that
flag
could somehow have a non-
true
-or-
false
value without undefined behavior at the point of reading it, but I'm not sure whether this is possible.

Answer

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.


EDIT

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()
{
    func(const_cast<bool&>(foo));
}

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).