On Sat, Jun 27, 2009 at 12:48 AM, Ian Lance Taylor<iant@xxxxxxxxxx> wrote: > Frank Neuhaus <dtag00@xxxxxxxxx> 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. 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. (*) The only exception would be if pixels pointed to itself... So that a change to pixels would somehow alter the pointer itself. Is this the case that the compiler is trying to catch here? Oh and if the compiler really has no way to cache this if resize is not inlined: Say you are writing an image class. Now say you are passing a const Image& around to some functions operating on this image. Obviously, the optimizer of those functions is never able to observe the whole "life" of "pixels". Are you saying that instead of using img.pixels[..] inside loops, one should always manually cache img.pixels? That somehow doesn't seem right to me... Thanks Frank
