Daniel Jacobowitz wrote: > On Fri, Nov 16, 2007 at 03:03:15PM -0500, Diego Novillo wrote: >> I'm not sure if it's intended, but I don't think it's desirable. The >> information needed to do LTO optimizations should be independent from the >> debugging information. > > FWIW, I disagree - not least because this makes GCC much more sensitive > to the correctness of its debugging output!
Right. In these discussions about DWARF-for-LTO, it's important to remember several things that went into the design. Some of these things have changed, and so maybe things about DWARF-for-LTO should change too, but they're still relevant for perspective. Here are three of the goals: 1. One goal was a compiler-independent (or, at least, GCC-version-independent) representation. We gave up on that for function-body representations, but the original LTO design (as circulated back in late 2005) had us designing a compiler-independent representation of expressions, too, with the goal of enabling non-LTO uses (such as IDEs, code-analysis tools, etc.). 2. Another goal was not to make .o files larger by duplicating the debug information for LTO. LTO needs names and types of functions; so does DWARF. 3. Finally, we felt DWARF was already designed for some combination of compactness and ability to skip about in the representation (rather than having to un-serialize everything to get any information) so it seemed a plausible representation format. 4. As Daniel says, a secondary goal was to improve GCC's debug information by making its correctness imperative for LTO. If all we care about is performance, that might not matter much -- but as per recent discussions on this list, many users care a lot about debugging information and the debugging experience, so improving debug information quality seems beneficial. For example, capturing GNU attributes in debug information for LTO will also debuggers and other tools that peer at debug information to have a more accurate view of the program. If we decide that we want to put the LTO declarative information in a separate section, we might well be able to do better than DWARF. I don't feel like we know enough yet to do that. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
