At the summit, I discovered two things about the internal representation
of debugging information:
1) According to Honza, the instances of the BLOCK tree type take 30% of
the space in a compilation.
2) The BLOCKS structure is linked in a way so that the blocks for one
function link to the blocks o
On Sun, Jul 22, 2007 at 07:37:43PM -0400, Kenneth Zadeck wrote:
> I find it somewhat surprising that we need so many blocks. My
> experience is that in real programs few blocks actually have any local
> declarations and it appears that we do not bother to get rid of the
> blocks that have no local
Hi,
to add some extra data
> At the summit, I discovered two things about the internal representation
> of debugging information:
>
> 1) According to Honza, the instances of the BLOCK tree type take 30% of
> the space in a compilation.
this large portion appears on C++ testcases doing a lot of in
On Mon, Jul 23, 2007 at 07:33:46PM +0200, Jan Hubicka wrote:
> The particular problem here is that the abstract origin pointers points
> to the blocks within functions they was constructed from. These are used
> by dwarf2out to output abstract copy of the function and then use it
> as a destination
> On Mon, Jul 23, 2007 at 07:33:46PM +0200, Jan Hubicka wrote:
> > The particular problem here is that the abstract origin pointers points
> > to the blocks within functions they was constructed from. These are used
> > by dwarf2out to output abstract copy of the function and then use it
> > as a d
On Mon, Jul 23, 2007 at 08:56:11PM +0200, Jan Hubicka wrote:
> > On Mon, Jul 23, 2007 at 07:33:46PM +0200, Jan Hubicka wrote:
> > It's mostly supposed to be a space optimization. We get e.g. the
> > names and (sometimes) types of local variables from the origin copy,
> > and only need a location a
Jan Hubicka wrote:
Thanks for explanation - the space optimization seems relatively
chalenging to implement, in particular because the variables in scope
might change in between the time abstract copy is output and the time
the block referencing to the block via abstract pointer is output.
The
Jason Merrill wrote:
> Jan Hubicka wrote:
>> Thanks for explanation - the space optimization seems relatively
>> chalenging to implement, in particular because the variables in scope
>> might change in between the time abstract copy is output and the time
>> the block referencing to the block via a
> Jan Hubicka wrote:
> >Thanks for explanation - the space optimization seems relatively
> >chalenging to implement, in particular because the variables in scope
> >might change in between the time abstract copy is output and the time
> >the block referencing to the block via abstract pointer is ou
