Re: GCC 3.4 and broken inlining.

[Timothy Miller]

William Lee Irwin III wrote:
> On Fri, Jul 09, 2004 at 08:24:03AM +0200, Arjan van de Ven wrote:
>
> > > one thing to note is that you also need to monitor stack usage then :)
> > > inlining somewhat blows up stack usage so do monitor it...
>
>
> On Sat, Jul 10, 2004 at 03:21:17AM +0200, Adrian Bunk wrote:
>
> > How could inlining increase stack usage?
>
>
> As more variables go into scope, gcc's stack slot allocation bug bites
> progressively harder and stackspace requirements grow without bound.


Blah... you should see what Sun's compiler does with volatiles.

Imagine you have some pointers like this:

volatile int *a, *b, *c, *d, *e;

And they are all valid pointers.

And then you have an expression like this:

x = ((((*a + *b) + *c) + *d) + *e);

Since *a and *b are volatile, the Sun compiler thinks that the sum of 
the two is also volatile, allocates stack space for it.  It computes (*a 
+ *b), stores it on the stack, and then loads it back from the stack, 
and then computes that plus *c, stores that result on the stack, then 
reloads it, etc.

I had a case where pointers had to be volatile, because I needed the 
memory space (over PCI) read at the right point in the code, and I 
needed to do some math on what was read.  I had 32 lines of code each of 
which got allocated 5 temporary variables on the stack, for absolutely 
no good reason.  The solution was to cast away the volatile a la ((int)*a).

Now, we all know that it makes no sense for the sum of two volatiles to 
also be volatile.  Once *a and *b are dereferenced and their sum 
computed, the sum isn't going to change, and it isn't even an lvalue, so 
nothing can modify it!

So, you want to talk about bugs.... give GCC a little slack.  :)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/