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.

Reply via email to