This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Reusing stack space for variables recorded during gimple lowering


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'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

Attachment: st1.c
Description: Text document

Attachment: st2.c
Description: Text document

Attachment: stack_usage.patch
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]