This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Code Bloat g++
- To: martin at loewis dot home dot cs dot tu-berlin dot de, pfeifer at dbai dot tuwien dot ac dot at
- Subject: Re: Code Bloat g++
- From: Mike Stump <mrs at windriver dot com>
- Date: Fri, 18 Feb 2000 16:58:59 -0800 (PST)
- Cc: gcc at gcc dot gnu dot org, jbuck at possibly dot synopsys dot com
> Date: Fri, 18 Feb 2000 22:17:48 +0100
> From: "Martin v. Loewis" <martin@loewis.home.cs.tu-berlin.de>
> Now, of course, I'm somewhat confused that this bracketing is
> included in the debug information. I'd guess that the original
> function (i.e. HeuristicPT::CreatePTs(void)) indeed contains as many
> left and right brackets, as indicated above.
> From looking at binutil's stab.def, one purpose of left and right
> bracket indication is to explain visibility of local variables to the
> debugger. The local variables would normally precede the LBRAC, and
> would be indicated by a stabs 128 (LSYM). In this case, they certainly
> don't serve this purpose - the blocks in questions don't have any
> locals.
> Perhaps the LBRAC and RBRAC records serve an additional purpose even
> in absence of any local variables? Or, would it be possible to
> eliminate these records of there are no automatic variables in a
> block? Any comments appreciated.
I know what the problem may be. We need a LBRAC/RBRAC eliminator.
Internally g++ uses bracketing for EH regions, and we introduce tons
of them for various things. I go back after and omit trivial regions
from the output, but never clean up the trivial LBRAC/RBRAC blocks.
If there is no reason to keep these blocks if they don't have user
visible/user desirable things, then we should omit all unwanted
trivial LBRAC/RBRAC blocks. So, the open question is, when do we want
to retain them?
Also, it may be a simple case of not managing `keep' correctly in the
C++ frontend.
This may speed up as and impove the debug size.