Unexpected optimizer behavior

[Andrew Haley]

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.
>>
>> 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.

Well, I did tell you.  :-)

No, that's not it.  gcc doesn't look inside resize() when it's
compiling main().  So, it doesn't know what resize() does.

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

I have no idea what you might be afraid of.  But the more the
compiler inlines, the more it can do, because the more it can see.

Andrew.