On Wed, 30 Oct 2019, Alexandre Oliva wrote: > On Oct 28, 2019, Richard Biener <rguent...@suse.de> wrote: > > > I guess you need to elaborate on 'per-file'. With LTO as far as I > > understand you'll get the graph per LTRANS unit (did you check > > where the output is generated?). > > Yeah, I guess this was not designed with LTO in mind; it probably even > predates LTO. We get per-LTRANS unit indeed, and the output is > generated in the temporary dir, which is not desirable behavior for > sure. The outputs seem to be usable if you can figure out what they > are, but I'm not sure how to go about combining the multiple .ci files, > or how to name the combined output, since it's not generally expected > that these files will be created at link time, rather than at compile > time. I'll bring this up internally and come back with some > improvement. > > > Is this mainly a debugging tool or does it serve a different purpose? > > It feeds gnatstack, that's a tool to compute max stack depth and perform > other call graph analyzes. I don't think of it as a debugging tool. > > https://www.adacore.com/gnatpro/toolsuite/gnatstack > http://docs.adacore.com/live/wave/gnatstack/html/gnatstack_ug/index.html
Ah, thanks for clarification. One way of operation would be to generate the graph during the compilation step even with LTO though it then becomes much less precise. Note that during LTRANS you could get at the original file via the DECL_SOURCE_LOCATION of the TRANSLATION_UNIT_DECL each function is ultimately rooted in so there's the vague possibility to annotate the graph accordingly to help combining the output. Additional arguments to -fcallgraph-info might be used to direct the output to a specific directory as well. Richard.
