C compiler optimization - how it is done between modules?

Imagine 2 source files, called file1.c and file2.c. They are both compiled separately by the compiler, and linked at the final step. Consider optimization GCC -Ofast. They both have its corresponding header file and headers include each others.

file1:

//#include...

int bool_check;
int main(void) {
    bool_check = 1;    
    while (bool_check) {
        do_something(); //Defined in another file
    }
}

file2:

void do_something() {
    extern int bool_check;
    bool_check = 0;
}

In this example, file1 calls a function in file2.

• Is compiler/optimizer allowed to optimize the code in file1 saying bool_check will never get changed so we don't need to perform constant read-from-memory operation?
• If no, how does it know that function in file2 modifies the variable, if files are compiled separately?
• If yes, isn't this a compiler bug?

It is not the great real-life use case, but good for demonstration.

> Is compiler/optimizer allowed to optimize the code in file1 saying bool_check will never get changed so we don't need to perform constant read-from-memory operation?

No. It can only make that optimization if it can prove that bool_check actually isn't modified by the call to do_something(), which is only possible if it can see the code.

> If no, how does it know that function in file2 modifies the variable, if files are compiled separately?

Normally, it doesn't know. So it has to assume that do_something() might modify bool_check, which means that it has to reload it from memory after every call.

In general, if the compiler can't see the code for a called function, it must assume that function might read or write every global variable in the program, as well as every static, local or dynamic object whose address has "escaped" and could possibly be known to the called function. So all preceding writes to such objects must be stored to memory before the call, and all subsequent reads must be loaded after the call.

For example:

void other1(int *p);
void other2(void);

int foo() {
    int x, y, z;
    int *p = &z;
    other1(&x);
    x = 3;
    y = 5;
    *p = 7;
    other2();
    return x + y;
}

After the call to other2(), the compiler has to reload x from memory. It is possible that the call to other1() stashed the pointer to x in some shared object that other2() can also access, in which case other2() might have modified x through that pointer. Likewise, the x=3 has to actually store the value 3 into memory and can't be optimized away.

On the other hand, y=5 needn't store to memory, and y need not be reloaded after other2(); the address of y has never been taken and so no other code could "know" where it's located in order to modify it. In fact, y need not occupy memory at all; it can simply be replaced by an immediate constant in the return expression.

The same is true for z; even though its address has been taken, it has not been passed outside the function foo and so it has not "escaped". This logic is called escape analysis. So the compiler can optimize it away without changing the program's observable behavior.

Having said all this, modern toolchains are capable of link time optimization, in which the compiler emits not only assembly code for each source file (translation unit) but also some intermediate representation (IR) that describes the code's semantics in more detail. All of this information is then available to the linker, which can re-run optimization and code generation, now with the entire program "visible" at once. At this point, the optimizer can see that bool_check is modified by the call to do_something(), though that doesn't really change anything because the compiler had already assumed that it was. What's more relevant is that the optimizer can see which variables are not modified, and optimize away any dead stores or unnecessary reloads.