Re: [Tinycc-devel] Proposal for handling alloca(). Anyone see a problem with it?

[David A. Wheeler]

Daniel Glöckner:
> ({int x=1; x;}) puts a reference to x on vtop and leaves the block. We may 
> not reuse x's stack space...
> int f() {
>   return ({int x=1; x;})+({int y=2; y;});
> }
> is a more complete example that will fail using the intended optimization.

Ah, now I understand what you mean.  Okay.  But in _many_ circumstances the 
last statement returns void, and at the point of block closure we'll know that. 
 We could even copy the referent to the top and reclaim the rest, but I don't 
think there's a need for that.

Common practice may occasionally cause values to be unintentionally retained.  
E.g., printf and assignment return values, but few people put (void) in front 
of them.  So if printf(...) or x=y are the last statement in a nested block 
you'll force retention in a trivial optimizer (like what I suspect we'll end up 
with).  But that will just cause some optimizations to not be made, not to make 
tinycc not work.

Maybe there needs to be something in the tinycc documentation on "how to write 
code that optimizes well for tinycc". In this case, "append (void) before the 
last statement in a block, unless you ARE returning its value from the block, 
so that the block space can be completely reclaimed."  That assumes that we 
HAVE such an optimization, which we currently don't.

> ({}) may not be the only problematic situation.

Huh? It seems to me that ({}) has the void type, and thus there's no area to 
save on the stack when the block ends.  Same thing with {int i=3;}... since 
"int i=3;" returns void, there's nothing to retain.  Those constructs shouldn't 
cause a referent to be left behind when the block ends.

If anyone wants to create a patch that better reuses stack space, I'd love to 
see it. I suspect it will be needed for compiling the latest Linux kernel 
(which has smaller stack sizes).

--- David A. Wheeler