Re: Unexpected optimizer behavior

[Frank Neuhaus <dtag00 at gmail dot com>]

On Fri, Jun 26, 2009 at 11:33 PM, Andrew Haley<aph@redhat.com> wrote:
> Frank Neuhaus wrote:
>> On Fri, Jun 26, 2009 at 8:36 PM, Andrew Haley<aph@redhat.com> wrote:
>>
>>> If gcc inlines Image::resize, it knows that pixels does not escape, and whatever
>>> is in pixels cannot have any effect elsewhere.
>>>
>> I still don't precisely understand the reason for this behavior.
> Well, I did tell you.  :-)

Well kind of. You said: "If gcc inlines Image::resize, it knows that
pixels does not escape, and whatever
is in pixels cannot have any effect elsewhere."

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?)

Thanks
   Frank