On Fri, Jun 26, 2009 at 8:36 PM, Andrew Haley<aph@xxxxxxxxxx> wrote: > If gcc inlines Image::resize, it knows that pixels does not escape, and whatever > is in pixels cannot have any effect elsewhere. > To learn more, compile with -fdump-tree-all and look at x.cc.*t.optimized. > You may find it interesting. Hm ok that indeed looks interesting. However as i see it it only shows me the way the optimizer laid things out, not the reason for why it is this way, right? I still don't precisely understand the reason for this behavior. I can only imagine that the compiler is "afraid" that the pointer img.pixels changes during the loop and thus it believes it needs to look it up in every single iteration. (Even though changes to the pointer could only possibly happen if pixels pointed to itself, I believe, right?). How does inlining resize change anything about this? Also what would happen if resize was called somewhere else in a complex function that can't be inlined for some reason? Then even inlining wouldn't help right? Would -O3 always do the trick or are there cases where I still need to be afraid that this happens? Thanks again Frank (Sorry accidently didn't reply to the newsgroup but to you personally in the first place)
