Frank Neuhaus wrote:
> Hi,
>
> I am looking at a case where the gcc's optimizer shows some
> 'unexpected' behavior:
> Please look at this code:
>
> #include <stdio.h>
>
> struct Image
> {
> Image()
> {
> w=h=0;
> pixels=0;
> }
> ~Image()
> {
> delete[] pixels;
> }
> void resize(int width, int height);
> int w;
> int h;
> unsigned char* pixels;
> };
>
> /* inline */ void Image::resize(int width, int height) // HERE
> {
> pixels=new unsigned char[width*height];
> w=width;
> h=height;
> };
>
> int main()
> {
> Image img;
> img.resize(400,300);
>
> for (int i=0;i<50000;i++)
> for (int y=0;y<300;y++)
> for (int x=0;x<400;x++)
> img.pixels[y*400+x]=17;
>
> printf("Done! %d",img.pixels[50]); // make sure the optimizer does
> not throw everything away :)
> return 0;
> }
>
> I highlighted one line with "HERE":
> If I inline the function resize, everything performs as expected.
> Specifically the loop in the main function is performed very fast
> (takes like 3.8 sec on my machine). However if I do _not_ inline the
> function "resize", it seems like it affects the way the loop in the
> main function is compiled. The program suddenly runs twice as long. I
> looked at the assembly that is being generated and it seems like
> img.pixels no longer gets cached in a register, but instead it
> retrieves the pixels variable every single loop iteration from the img
> struct.
>
> I am compiling with g++ -O2. The problem does not appear to show up
> with -O3 (at least I was not able to reproduce it). The question is:
> Why does the optimizer show the above behavior? Why does inlining (or
> not) a marginally related function affect this loop which basically
> has nothing to do with "resize"?
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.
Andrew.
