Frank Neuhaus wrote: > 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. This assumption is wrong. main() is called by another function, usually something in crtn, and gcc has no way to know that the calling function will not access pixels when main() exits. Andrew.
