Re: Unexpected optimizer behavior

[Frank Neuhaus <dtag00 at gmail dot com>]

On Sat, Jun 27, 2009 at 1:16 AM, me22<me22.ca@gmail.com> wrote:
> 2009/6/26 Frank Neuhaus <dtag00@gmail.com>:
>>
>> Yes I agree that since resize is not inlined, the way pixels changes
>> during the resize call is unknown to the optimizer operating on main.
>> But _after_ this call to resize, all changes to pixels _have_ to be
>> caused by main, and thus are known to the optimizer of the main
>> function. That means it should be able to tell that pixels cannot
>> possibly change after the execution of resize(*). And more
>> specificially that it cannot possibly change during the execution of
>> the loop.
>>
>
> What if resize spawns a thread that wakes up periodically to change
> the value? ?The compiler can't assume "well-behaved" functions.

Compilers such as gcc (and other compilers) do not handle
multithreading issues like this. It's up to the programmer to deal
with that. It is impossible to catch all those errors for a compiler.
Also even in this simple case, not caching the pointer would still not
make it thread safe. At some point it will read the img.pixels
variable into a register, and then write to the memory that the
register points to. If another thread changes pixels after pixels was
read into the register, things would be wrong already...