Re: lto gimple types and debug info

[Mark Mitchell <mark at codesourcery dot com>]

David Edelsohn wrote:

> 	I do not expect LTO (or WHOPR) to work on AIX -- at least not
> without a lot of work on wrappers around the AIX linker.  However, I do
> not understand why enhancing GCC to support LTO -- when GCC is run without
> enabling LTO -- requires locking GCC completely into DWARF debugging.

I agree that, at least in principle, it should be possible to emit the 
debug info (whether the format is DWARF, Stabs, etc.) once.  So, I don't 
see a reason that this makes us a DWARF-only compiler either.

Others have raised the issue of types which are fundamentally 
transformed by the compiler (such as by removing fields).  I think that 
such opportunities are going to be relatively rare; the global "struct 
Window" object in a GUI library full of functions taking "struct Window 
*" parameters probably isn't optimizable in this way.  But there will be 
situations where this is possible and profitable of course.

In that case, I'm not sure that *type* ought to be modified at all, from 
the debug perspective.  To the extent there's still an object of type 
"struct X" around, it's type is still what it was.  And other things you 
might do in a debugger, like ask "What member functions does class X 
have?", have the same answer no matter the layout chosen by the 
compiler, including throwing out half the fields and leaving the rest in 
random registers.  For that matter, "print sizeof(X)" should print the 
same value when debugging optimized code as when debugging unoptimized 
code, even if the compiler has optimized X away to an empty structure!

There are other things we could do, like mark the *variables* of type X 
(rather than the type) as having no location, so that you can't 
print/modify objects that have been optimized in this way.  That 
reflects more accurately the user's view of what has happened; it's not 
that the type itself is different as much as it is that objects of the 
type are hard to view.

You could also add a marker to the type that says "optimized madly; 
debugger should proceed with caution" -- and you could do that without 
reloading and rewriting the type information.  For example, when 
generating the original type debug info, emit a relocation against 
"X_optimized_madly" and then providing an approprivate value for the 
symbol at link time.

I'm curious what we do with SRA at the moment.  This is the same sort of 
problem; do we have any solutions at present?

--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713