Unexpected optimizer behavior

[Ian Lance Taylor]

Frank Neuhaus <dtag00@gmail.com> writes:

> I would just like to know how the behavior prevents those 'bad' things
> from happening i.e.:
> How does not caching the pixels pointer in a local variable in front
> of the loop prevent pixels from "escaping"? (What does that mean by
> the way if a pixel "escapes"?)
> How does not caching the pixels pointer, prevent pixels to have
> "effects elsewhere"? Or vice versa: How does caching the pixels
> pointer cause "effects elsewhere"? (Again: What are those "effects"
> that could be caused?)

I think you are asking the question the wrong way around.  After
inlining, gcc compiles a single function at a time (with some exceptions
I won't discuss here).  If gcc sees every use of the pixels pointer,
then it knows that it can cache it locally.  If gcc does not see every
use--e.g., because it is passed to another function or stored in a
global variable--then gcc does not know how it may be changed by code it
can not see, and therefore can not cache it locally.

Ian