[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Tinycc-devel] Proposal for handling alloca(). Anyone see a problem
From: |
David A. Wheeler |
Subject: |
Re: [Tinycc-devel] Proposal for handling alloca(). Anyone see a problem with it? |
Date: |
Tue, 08 May 2007 16:54:27 -0400 (EDT) |
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
- Re: [Tinycc-devel] Proposal for handling alloca(). Anyone see a problem with it?, (continued)
- Re: [Tinycc-devel] Proposal for handling alloca(). Anyone see a problem with it?, Rob Landley, 2007/05/07
- Re: [Tinycc-devel] Proposal for handling alloca(). Anyone see a problem with it?, Dave Dodge, 2007/05/08
- Re: [Tinycc-devel] Proposal for handling alloca(). Anyone see a problem with it?, Fred Weigel, 2007/05/08
- Re: [Tinycc-devel] Proposal for handling alloca(). Anyone see a problem with it?, Daniel Glöckner, 2007/05/08
- Re: [Tinycc-devel] Proposal for handling alloca(). Anyone see a problem with it?, David A. Wheeler, 2007/05/08
- Re: [Tinycc-devel] Proposal for handling alloca(). Anyone see a problem with it?, Daniel Glöckner, 2007/05/08
- Re: [Tinycc-devel] Proposal for handling alloca(). Anyone see a problem with it?,
David A. Wheeler <=
- Re: [Tinycc-devel] Proposal for handling alloca(). Anyone see a problem with it?, Philippe Ribet, 2007/05/10
- Re: [Tinycc-devel] Proposal for handling alloca(). Anyone see a problem with it?, David A. Wheeler, 2007/05/10
- Re: [Tinycc-devel] Proposal for handling alloca(). Anyone see a problem with it?, Rob Landley, 2007/05/11
Re: [Tinycc-devel] Proposal for handling alloca(). Anyone see a problem with it?, Dave Dodge, 2007/05/08