Re: debugging info considered harmful to lto.

[Jan Hubicka <jh at suse dot cz>]

> 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 of origin pointers from every copy of the function.
> > (I am not sure what the block origins are neede for by GDB, explanation
> > would be welcome)
> 
> 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 at each inlining site.  I'm sure there are
> other things we could do with this information, that rely on knowing
> what variables are the same from the user's point of view.

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.

How things are compared to match and where the optimization is done?

We have origin pointers in declarations and origin pointers in blocks.
I guess optimization willing to know all variables same from user POV
(for lets say setting watchpoint on something in inline function)
probably cares about origins of declarations rather than blocks. 

At what time the blocks actually matters?

For example if I have block that contians just single block and declare
no new variables, can I simply remove it and replace it by the inner
block?

Honza
> 
> -- 
> Daniel Jacobowitz
> CodeSourcery