This is the mail archive of the gcc-patches@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]

Re: [patch] better dwarf2 debug info for inlined functions


On Wed, 2005-07-06 at 20:47, Daniel Berlin wrote:
> Since you only set block_source_location on top level blocks ("This is
> only set in the top level block, which corresponds to the inlined
> function scope."), it might make more sense to use a hashtable or
> something to store this data on the side for just those blocks rather
> than put a location in *every single block*.

I was following the precedent set by Richard Henderson's earlier patch,
which also put related info in the block structure; info which is only
needed by some blocks.  Putting info in the block structure ensures it
will be preserved along with other info in the block as the blocks get
moved around.

I'll try taking a look at how often the extra info is used, and how it
affects run time memory size.

Also, I'll try to see if the info can be put elsewhere, but at first
glance I'm not sure how this can work.  blocks don't have a unique
identifier, and their addresses can change, so we don't have anything
convenient to use to index into a hash table.  I think I'd have to add a
unique identifier field, and then add code to maintain it, plus code to
create a hash table for extra info, plus code to manage the hash table
info when blocks are split/merged/reordered/etc during optimization. 
I'm skeptical that the extra complexity is worth the space savings.  You
don't have these kinds of problems with decl info.  Once a decl is
created, we don't do much with it, other than maybe deal with duplicate
decls.  And decls already have a uid.
-- 
Jim Wilson, GNU Tools Support, http://www.specifix.com


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