On Fri, Jun 16, 2017 at 6:35 PM, Pierre-Marie de Rodat <dero...@adacore.com> wrote: > On 05/31/2017 11:08 AM, Pierre-Marie de Rodat wrote: >> >> On 05/31/2017 09:34 AM, Richard Biener wrote: >>> >>> Actually for the bigger picture I'd refactor >>> rest_of_decl_compilation, not calling it from the frontends but >>> rely on finalize_decl/function. The missing part would then be >>> calling the dwarf hook which should eventually be done at some of >>> the places the frontends now call rest_of_decl_compliation. > > > I put some thought about this, but I suppose I don’t yet understand well > enough the relation between what rest_of_decl_compilation and > finalize_decl/function do. So I’ve tried to go half-way: I moved the > “specification?” guard from the DWARF back-end to callers of the > early_global_decl hook. In the end, this yielded a very small middle-end > change: almost all hook calls in front-ends are for variables or namespaces, > not for functions. > >>> But for an easier way (you might still explore the above ;)) just remove >>> the guards from dwarf2out.c and handle it more like types that we >>> prune if they end up being unused (OTOH I guess we don't refer to >>> the decl DIEs from "calls" because not all calls are refered to with >>> standard DWARF -- the GNU callsite stuff refers them I think but those >>> get generated too late). >>> >>> That said, when early_finish is called the cgraph and IPA references >>> exists and thus you can >>> sort-of see which functions are "used". >> >> >> Ok, thanks. I’ll give a try to the first option, then. :-) > > > I finally decided not to implement this scheme, as it does not give the same > results for the case in Ada that motivated this change: it would generate > potentially one DIE per “calling unit” per called function, which is quite > suboptimal compared to one DIE per subprogram definition or subprogram > import. This would look like a debug info bloat for debatable gain. > > So here’s an updated patch, without the new debug hook. It boostrapped and > regtested fine on x86_64-linux. After this change, I observed an increase > of: > > * an increase of ~22KB for gnat1 (base is 210MB); > * a decrease (?) of ~3KB for cc1 (base is 197MB); > * a similar decrease of 3KB for cc1plus (base is 220MB). > > Ok to commit?
Nice. This looks ok. I'm mildy curious about the deecrease of debuginfo size for cc1 -- did you spot anything obvious there? I suspect Fortran wants to do sth similar as Ada for imported modules. Thanks, Richard. > -- > Pierre-Marie de Rodat
