On Jun 7, 2008, at 3:51 PM, Hamish Allan wrote:
Sorry to reply to myself, but I just remembered that pointers in registers are also in the root set! That said, I don't think it changes the substance of my proposal: that stack variables (i.e. variables semantically placed on the stack by the programmer) should remain in the root set until they are out of scope (i.e. semantically no longer in the current stack frame).
That leads to significantly slower code. If you have some C based performance test suite available, compile it at the different optimization levels and see how the numbers change. You can even turn on/off specific optimizations and see the impact.
In particular, a common optimization is to use registers to store local variables and/or arguments. This would no longer be viable if the compiler couldn't recycle locals when they fall out of scope. Or it would be exceedingly expensive as the compiler would have to generate code to save and restore registers across call sites.
Consider:
{
int foo;
... calculate on foo ...
int bar = getirdone(foo);
while(1) {
func(bar);
func2(bar);
... etc ...
}
}
Without being able to recycle the space used by foo and bar, the
compiler will generate code the pays the price of that space being
consumed for all of the while loop, which could be the vast majority
of the run time of the application.
As well, if foo / bar fall in a register, then those registers would have to be preserved for all of the while loop, too, either by not being available to the bulk of the program (which raises some serious codegen issues) or being moved out/in the registers every time one of the funcs in the while loop is called or returns.
One of the tenets of GCC is that *it controls the layout of the stack always* and this is done quite explicitly because of performance.
b.bum
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
