site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com On Mar 3, 2009, at 2:00 PM, Brian Mastenbrook wrote: On Mar 3, 2009, at 3:35 PM, Ryan McGann wrote: Thanks, Ryan _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... We have some sample code that shows that the temporary returned from the function doMath is allocated stack space twice, when it can only be used once. But since the function in our actual production code is pretty complex, it's hard to know hwich problem we are experiencing. However, the above examples are both well documented cases of GCC problems; I actually got the basic ideas for both examples from Linus Torvald's (sometimes long) emails regarding Linux's problems with GCC stack allocation. I've been bitten by this problem in the past as well, especially in functions that look a lot like the examples you've given (where an outer if wraps several complex code blocks). The worst of it is that in this example: Yes, it looks like we are running into that problem. We don't have any large structures allocated on the stack, but a couple of ints here and there start to add up. In addition, it seems like GCC handles temporaries equally poorly. We have some code blocks that are very deeply nested due to switch statements and if/else blocks, and gcc seems to not know that certain temporaries it created for statements in the if condition can go away once the if statement has been evaluated. We have a lot of code that looks like: switch(something) { case blah: { if ((scanner->get_offset() + buffer_manager->get_offset() + scanner->start()) < cur_offset) { } } break; } GCC does all the math using temporaries, and then never realizes that the stack space for the temporaries can be re-used once the if statement has been evaluated. I tried turning off inlining--all those get() functions above are one line functions implemented in the header file, so gcc inlines them--but that seems to make little difference, which makes sense since all those "functions" are not really doing anything. There are still a few options left to you that I can think of. The first is to use LLVM - but in a slightly different way. Try running the code through llvm-gcc with the C backend, and fiddling with the different LLVM optimization settings. It's possible that llvm's better analysis of local variable liveness will result in (mangled and unreadable) C output that doesn't demonstrate the problem. Interesting. From the --help for llvm-gcc-4.2 I can't make much sense of it, or at least how to specify the output type. Whenever I tired it it seemed to just call gcc, but I'll have to play with it more. But since our library (and this function) is C++ not sure I can use this option anyway. Another option would be to hack up a transformer using clang (assuming your code is pure C), which would perform directed partial outlining on the functions you've identified to be problematic. Alas the code is C++. It's not *really* C++, as it doesn't even use virtual functions--it's more like structs with operator new() overriden to use lookaside lists, but still not pure C. This email sent to site_archiver@lists.apple.com