On Fri, May 18, 2012 at 10:18 PM, Andrew Jenner <and...@codesourcery.com> wrote: > I'm investigating the reason why the amount of stack used by some pieces of > code increased significantly since gcc 3.3. Notably, > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25505 has a testcase which went > up from 512 bytes to 20K between gcc 3.3 and 4.x, then back down to ~5K with > later optimizations. > > I've tracked down the remainder of the regression to variables recorded > during gimple lowering - these variables have a scope larger than they > really need to (the entire function), so don't share stack space with each > other or anything else. The two testcases attached (st1.c and st2.c) should > ideally use the same amount of stack but currently don't. > > I've been playing with variations on the attached patch (which is against > gcc 4.1 but I think the mainline version will be very similar). This does > cause the compiler to generate the same assembly for st1.c as for st2.c. > However, it ICEs on this simple testcase: > > int foo (void) > { > if (0) > { > return 0; > } > return 1; > } > > This seems to be because in gimple-low.c, the BLOCK_SUBBLOCKS of the > DECL_INITIAL block is cleared and never reconstructed, due to new_block and > old_block being the same in lower_bind_expr. This leads to the VAR_DECLs of > the temporary variables not being seen during expand_used_vars.
I don't think any of BLOCK matters in GCC 4.7 any more for stack sharing. You should be able to emit a CLOBBER for those variables and the rest should just work. Can you try with GCC 4.7.0 if that does not work, try emitting a CLOBBER? Thanks, Andrew Pinski > > I'm not quite sure what it is about the trees I'm generating that > gimple-low.c doesn't like. > > Is there a way to make this patch work, or is this approach doomed for some > reason that I haven't understood? > > Thanks, > > Andrew
