This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: Unexpected optimizer behavior
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. 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)