Re: drop -aux{dir,base}, revamp -dump{dir,base} (was: Re: introduce -fcallgraph-info option)

[Richard Biener]

On Thu, 26 Dec 2019, Alexandre Oliva wrote:

> On Dec 25, 2019, Alexandre Oliva  wrote:
> 
> > 3. do not take the executable name into account when it shares the
> > basename with an input file; combine executable basename with input name
> > otherwise.  this makes gcc -o foo[.exe] -g -gsplit-dwarf foo.c output
> > foo.dwo rather than foo-foo.dwo, which is nice, but then dwo files
> > compiled for use with foo won't all match foo-*.dwo; it seems more
> > desirable that they all do
> 
> > 4. same as above, but only when there is only one input file, so that
> > after adding bar.c to the command above, you'd get foo-foo.dwo and
> > foo-bar.dwo
> 
> > Me, I'm leaning towards 5.
> 
> And yet I ended up implementing 4 after some more thinking, because the
> point was to reduce gratuitous and unnecessary changes.
> 
> 
> Here's my first cut at documenting all of the various complex
> interactions between -o, -dumpbase, -dumpbase-ext, -dumpdir, and
> save-temps=*
> 
> Is this too cryptic, to the point of requiring lots of examples to make
> it understandable, or is this usable enough?

It's understandable and indeed also very helpful.  So I agree to go
forward with this (variant 4).

Did I miss the actual (non-documentation) patch?

Thanks,
Richard.

> 
> @@ -1561,6 +1563,89 @@ assembler file in @file{@var{source}.s}, a precompiled 
> header file in
>  @file{@var{source}.@var{suffix}.gch}, and all preprocessed C source on
>  standard output.
>  
> +
> +@item -dumpbase @var{dumpbase}
> +@opindex dumpbase
> +This option sets the base name for auxiliary and dump output files.  It
> +does not affect the name of the main output file, implied or specified
> +with @option{-o}.  It may affect intermediate outputs, however:
> +
> +@smallexample
> +gcc -save-temps -S foo.c&
> +@end smallexample
> +
> +saves the (no longer) temporary preprocessed file in @file{foo.i}, and
> +then compiles to the (implied) output file @file{foo.s}, whereas:
> +
> +@smallexample
> +gcc -save-temps -dumpbase save-foo -c foo.c&
> +@end smallexample
> +
> +preprocesses to in @file{save-foo.i}, compiles to @file{save-foo.s} (now
> +an intermediate, thus auxiliary output), and then assembles to the
> +(implied) output file @file{foo.o}.
> +
> +If absent, dump and aux files their names from the input file, or from
> +the (non-linker) output file, if one is explicitly specified: dump
> +output files (e.g. those requested by -fdump-* options) with the input
> +name suffix, and aux output files (those requested by other non-dump
> +options, e.g.  @code{-save-temps}, @code{-gsplit-dwarf},
> +@code{-fcallgraph-info}) without it.  
> +
> +Similar suffix differentiation of dump and aux outputs can be attained
> +for explicitly-given @option{-dumpbase basename.suf} by also specifying
> +@option{-dumpbase-ext .suf}.
> +
> +If @var{dumpbase} is explicitly specified with any directory component,
> +@option{-dumpdir} and other @var{dumppfx}-setting @option{-save-temps=*}
> +options are ignored, and instead of appending to it, @var{dumpbase}
> +fully overrides it.
> +
> +When @option{-dumpbase} is specified in a command that compiles multiple
> +inputs, or that compiles and then links, it may be combined with
> +@var{dumppfx}, as specified under @option{-dumpdir}, and each input file
> +is then compiled using the combined @var{dumppfx}, and default values
> +for @var{dumpbase} and @var{auxdropsuf} computed for each input file.
> +
> +
> +@item -dumpbase-ext @var{auxdropsuf}
> +@opindex dumpbase-ext
> +When forming the name of an auxiliary (but not a dump) output file, drop
> +trailing @var{auxdropsuf} from @var{dumpbase} before appending any
> +suffixes.  If not specified, this option defaults to the suffix of the
> +input file, including the period.
> +
> +
> +@item -dumpdir @var{dumppfx}
> +@opindex dumpdir
> +When forming the name of an auxiliary or dump output file, use
> +@var{dumppfx} as a prefix.  If it is to be used as a directory name, it
> +must end with a directory separator.
> +
> +It defaults to the location of the output file; options
> +@option{-save-temps=cwd} and @option{-save-temps=obj} override this
> +default, just like an explicit @option{-dumpdir} option.  In case
> +multiple such options are given, the last one prevails.
> +
> +When compiling from multiple input files, if @option{-dumpbase} is
> +specified, @var{dumpbase}, minus a @var{auxdropsuf} suffix, and a dash
> +are appended to (or override, if containing any directory components) an
> +explicit or defaulted @var{dumppfx}, so that each of the multiple
> +compilations gets differently-named aux and dump outputs.
> +
> +When compiling and then linking from multiple input files, a defaulted
> +or explicitly specified @var{dumppfx} also undergoes the @var{dumpbase}-
> +transformation above.  If neither @option{-dumpdir} nor
> +@option{-dumpbase} are given, the linker output base name, minus the
> +executable suffix, plus a dash is appended to the default @var{dumppfx}
> +instead.
> +
>

drop -aux{dir,base}, revamp -dump{dir,base} (was: Re: introduce -fcallgraph-info option)

[Alexandre Oliva]

On Dec 25, 2019, Alexandre Oliva  wrote:

> 3. do not take the executable name into account when it shares the
> basename with an input file; combine executable basename with input name
> otherwise.  this makes gcc -o foo[.exe] -g -gsplit-dwarf foo.c output
> foo.dwo rather than foo-foo.dwo, which is nice, but then dwo files
> compiled for use with foo won't all match foo-*.dwo; it seems more
> desirable that they all do

> 4. same as above, but only when there is only one input file, so that
> after adding bar.c to the command above, you'd get foo-foo.dwo and
> foo-bar.dwo

> Me, I'm leaning towards 5.

And yet I ended up implementing 4 after some more thinking, because the
point was to reduce gratuitous and unnecessary changes.


Here's my first cut at documenting all of the various complex
interactions between -o, -dumpbase, -dumpbase-ext, -dumpdir, and
save-temps=*

Is this too cryptic, to the point of requiring lots of examples to make
it understandable, or is this usable enough?


@@ -1561,6 +1563,89 @@ assembler file in @file{@var{source}.s}, a precompiled 
header file in
 @file{@var{source}.@var{suffix}.gch}, and all preprocessed C source on
 standard output.
 
+
+@item -dumpbase @var{dumpbase}
+@opindex dumpbase
+This option sets the base name for auxiliary and dump output files.  It
+does not affect the name of the main output file, implied or specified
+with @option{-o}.  It may affect intermediate outputs, however:
+
+@smallexample
+gcc -save-temps -S foo.c&
+@end smallexample
+
+saves the (no longer) temporary preprocessed file in @file{foo.i}, and
+then compiles to the (implied) output file @file{foo.s}, whereas:
+
+@smallexample
+gcc -save-temps -dumpbase save-foo -c foo.c&
+@end smallexample
+
+preprocesses to in @file{save-foo.i}, compiles to @file{save-foo.s} (now
+an intermediate, thus auxiliary output), and then assembles to the
+(implied) output file @file{foo.o}.
+
+If absent, dump and aux files their names from the input file, or from
+the (non-linker) output file, if one is explicitly specified: dump
+output files (e.g. those requested by -fdump-* options) with the input
+name suffix, and aux output files (those requested by other non-dump
+options, e.g.  @code{-save-temps}, @code{-gsplit-dwarf},
+@code{-fcallgraph-info}) without it.  
+
+Similar suffix differentiation of dump and aux outputs can be attained
+for explicitly-given @option{-dumpbase basename.suf} by also specifying
+@option{-dumpbase-ext .suf}.
+
+If @var{dumpbase} is explicitly specified with any directory component,
+@option{-dumpdir} and other @var{dumppfx}-setting @option{-save-temps=*}
+options are ignored, and instead of appending to it, @var{dumpbase}
+fully overrides it.
+
+When @option{-dumpbase} is specified in a command that compiles multiple
+inputs, or that compiles and then links, it may be combined with
+@var{dumppfx}, as specified under @option{-dumpdir}, and each input file
+is then compiled using the combined @var{dumppfx}, and default values
+for @var{dumpbase} and @var{auxdropsuf} computed for each input file.
+
+
+@item -dumpbase-ext @var{auxdropsuf}
+@opindex dumpbase-ext
+When forming the name of an auxiliary (but not a dump) output file, drop
+trailing @var{auxdropsuf} from @var{dumpbase} before appending any
+suffixes.  If not specified, this option defaults to the suffix of the
+input file, including the period.
+
+
+@item -dumpdir @var{dumppfx}
+@opindex dumpdir
+When forming the name of an auxiliary or dump output file, use
+@var{dumppfx} as a prefix.  If it is to be used as a directory name, it
+must end with a directory separator.
+
+It defaults to the location of the output file; options
+@option{-save-temps=cwd} and @option{-save-temps=obj} override this
+default, just like an explicit @option{-dumpdir} option.  In case
+multiple such options are given, the last one prevails.
+
+When compiling from multiple input files, if @option{-dumpbase} is
+specified, @var{dumpbase}, minus a @var{auxdropsuf} suffix, and a dash
+are appended to (or override, if containing any directory components) an
+explicit or defaulted @var{dumppfx}, so that each of the multiple
+compilations gets differently-named aux and dump outputs.
+
+When compiling and then linking from multiple input files, a defaulted
+or explicitly specified @var{dumppfx} also undergoes the @var{dumpbase}-
+transformation above.  If neither @option{-dumpdir} nor
+@option{-dumpbase} are given, the linker output base name, minus the
+executable suffix, plus a dash is appended to the default @var{dumppfx}
+instead.
+
+When compiling and then linking from a single input file, the linker
+output base name will only be appended to the default @var{dumppfx} as
+above if it does not share the base name with the single input file
+name.
+
+
 @item -v
 @opindex v
 Print (on standard error output) the commands executed to run the stages


-- 
Alexandre Oliva, freedom fighter   he/him   https://FSFLA.org/blogs/lxo
Free Software Evangelist  

Re: introduce -fcallgraph-info option

[Alexandre Oliva]

On Nov  7, 2019, Alexandre Oliva  wrote:

> compiling a single source idir/ibase.iext:

>   -o odir/obase.oext specified: default -dumpdir odir -dumpbase obase.iext
>   -o obase.oext specified: default -dumpbase obase.iext
>   -o ibase.oext implied: default -dumpbase ibase.iext

> compiling multiple sources named as ibase.iext for linking:

>   -dumpbase [ddir/]dbase specified: make it -dumpbase [ddir/]dbase-ibase.iext
>   -o odir/output specified: default -dumpdir odir -dumpbase output-ibase.iext
>   -o output specified: default -dumpbase output-ibase.iext
>   -o a.out implied: default -dumpbase a.out-ibase.iext

> LTO recompiling:

>   same as above, with each ibase.iext set to ltrans#


> The resulting behavior (aux_base_name, dump_base_name)

> compiling and linking with -o: (outdir/runme-ibase, outdir/runme-ibase.iext)
> ex $CC -o outdir/runme srcdir/foo.c srcdir/x/bar.c
> -> /tmp/temp().o outdir/runme-foo.su outdir/runme-foo.c.#t.original
>  + /tmp/temp().o outdir/runme-bar.su outdir/runme-bar.c.#t.original
>  + outdir/runme

I've implemented this so that, even with a single source file, the
executable name is prepended to the aux outputs in the case above.  This
causes thousands of testsuite failures, as dump files generated by tests
that undergo linking were no longer found: since we compile
foo.ext -o foo.exe, dumps end up named foo-foo.ext.* rather than
foo.ext.*.

Although it doesn't seem too hard to fix the testsuite logic, I'm a
little hesitant at imposing this change onto such a common case that
might hit other tools that use gcc underneath.  I'm considering other
alternatives, such as:

1. do not take the executable name into account when naming aux outputs
of compilations, just like we do today.  this makes aux outputs for the
same input file overwrite each other.

2. do not take the executable name into account when there is a single
input file.  same problem as above

3. do not take the executable name into account when it shares the
basename with an input file; combine executable basename with input name
otherwise.  this makes gcc -o foo[.exe] -g -gsplit-dwarf foo.c output
foo.dwo rather than foo-foo.dwo, which is nice, but then dwo files
compiled for use with foo won't all match foo-*.dwo; it seems more
desirable that they all do

4. same as above, but only when there is only one input file, so that
after adding bar.c to the command above, you'd get foo-foo.dwo and
foo-bar.dwo

5. when there is a single input file, take the basename of the
executable alone, rather than combine it with the basename of the input
file, to name aux outputs, but still use the extension of the input
file, so gcc -o foo foo.c will generate foo.dwo and foo.c.* dumps

I dislike the asymmetry in 3., but I would be happy to implement any
other, including the testsuite change to accommodate foo-foo.* dumps.
Any preferences?  Me, I'm leaning towards 5.

-- 
Alexandre Oliva, freedom fighter   he/him   https://FSFLA.org/blogs/lxo
Free Software Evangelist   Stallman was right, but he's left :(
GNU Toolchain EngineerFSMatrix: It was he who freed the first of us
FSF & FSFLA board memberThe Savior shall return (true);

Re: introduce -fcallgraph-info option

[Alexandre Oliva]

On Dec  9, 2019, Richard Biener  wrote:

> On Tue, 3 Dec 2019, Alexandre Oliva wrote:

>> I'm considering rejecting command lines that specify both an explicit
>> -dumpdir and -save-temps=cwd, and in the absence of an explicit
>> -dumpdir, arranging for -save-temps=cwd or -save-temps=obj to override
>> what would otherwise be the default -dumpdir.

> Making -save-temps=cwd essentially a short-cut to -save-temps -dumpdir ./
> is fine I guess (we usually do not start to reject previously accepted
> options).

What if -save-temps=* and -dumpdir both set the same underlying aux
output dir, with the latest one in the command line prevailing, rather
than being rejected?

>> gcc -c foo.c -dumpbase foobar && gcc -c bar.c -dumpbase foobar
>> 
>> and
>> 
>> gcc -c foo.c bar.c -dumpbase foobar
>> 
>> The latter will name outputs after foobar-foo and foobar-bar,
>> respectively, whereas the former will overwrite outputs named foobar
>> when compiling bar.c.  Under the proposal to modify %b according to
>> -dump*, even object files would be named after an explicit -dumpbase,
>> when -o is not explicitly specified.

> I think rejecting option combinations that do not make much sense
> or would introduce inconsistencies like this is better than trying
> to invent creative things second-guessing what the user meant.

Hmm, I sense conflicting recommendations here vs the previous block ;-)
A single -dumpbase when compiling multiple sources used to be accepted,
after all, it just overrode aux outputs so only the last one prevailed.


> Hum.  I didn't notice -dumpdir is just a prefix and I wouldn't object
> to make it errorneous if it doesn't specify an acutal directory.

But would you object to retaining the ability to use it as a prefix?

> I also note that neither -dumpdir nor -dumpbase are documented
> in invoke.texi

*nod*

> Not sure if all this means we should document the altered behavior
> or if we should take it as a hint we can alter behavior at will
> (in future) ;)

I suppose we have more leeway in changing what's not even documented.


Thanks again for the feedback!

-- 
Alexandre Oliva, freedom fighter   he/him   https://FSFLA.org/blogs/lxo
Free Software Evangelist   Stallman was right, but he's left :(
GNU Toolchain EngineerFSMatrix: It was he who freed the first of us
FSF & FSFLA board memberThe Savior shall return (true);

Re: introduce -fcallgraph-info option

[Richard Biener]

On Tue, 3 Dec 2019, Alexandre Oliva wrote:

> On Nov 14, 2019, Alexandre Oliva  wrote:
> 
> > In order to address this, I propose we add an internal option (not for
> > the driver), -dumpbase-ext, that names the extension to be discarded
> > from dumpbase to form aux output names.
> 
> Here's a WIP patch that implements much of the desired semantics.
> 
> I'm still struggling a bit with -gdwarf-split and -save-temps; -dumpbase
> and multiple inputs, -dumpdir as a prefix, and -flto + -dump*.
> 
> -gdwarf-split uses %b to strip debug info into the .dwo file, so it
> lands in the same location as the .o, rather than in a named -dumpdir as
> specified in the .o debug info skeleton.  I'm thinking of arranging for
> -dump* flags to affect %b and %B, just like -save-temps does.  I've
> reviewed all uses of %b and %B, and it looks like this would enable us
> to fix the .dwo naming mismatch without significant complication.
> 
> Which brings us to the next issue.  This would cause -dumpdir to
> override the -save-temps location.  This is arguably an improvement.  It
> might conflict with -save-temps=cwd, however.
> 
> I'm considering rejecting command lines that specify both an explicit
> -dumpdir and -save-temps=cwd, and in the absence of an explicit
> -dumpdir, arranging for -save-temps=cwd or -save-temps=obj to override
> what would otherwise be the default -dumpdir.
> 
> Or, for the sake of simplifying and bringing more sanity to the logic of
> naming extra output files, we could just discontinue -save-temps=*, and
> require -dumpdir ./ along with plain -save-temps to get the effects of
> -save-temps=cwd.

Making -save-temps=cwd essentially a short-cut to -save-temps -dumpdir ./
is fine I guess (we usually do not start to reject previously accepted
options).  Auto-magically splitting this via the 'Alias' mechanism
isn't (yet) supported I think (split one option into two others).

> 
> When compiling multiple inputs with a single -dumpbase, the current
> implementation arranges for each compilation to take an adjusted
> -dumpbase appending - to the given dumpbase, minus extension.  An
> alternative would be to reject such compilations, just as we reject
> multiple compilations with a single object file named as output.  That
> feels excessive for -dumpbase, however.  OTOH, adjusting -dumpbase only
> when there are multiple inputs causes different behavior comparing:
> 
>   gcc -c foo.c -dumpbase foobar && gcc -c bar.c -dumpbase foobar
> 
> and
> 
>   gcc -c foo.c bar.c -dumpbase foobar
> 
> The latter will name outputs after foobar-foo and foobar-bar,
> respectively, whereas the former will overwrite outputs named foobar
> when compiling bar.c.  Under the proposal to modify %b according to
> -dump*, even object files would be named after an explicit -dumpbase,
> when -o is not explicitly specified.

I think rejecting option combinations that do not make much sense
or would introduce inconsistencies like this is better than trying
to invent creative things second-guessing what the user meant.

> Yet another thing I'm not so sure about is -dumpdir as a prefix, e.g.,
> in cases we're compiling multiple files and then linking them together,
> say 'gcc foo.c bar.c -o foobar', the proposal was to name dumps of the
> compilations after foobar-foo and foobar-bar, respectively.
> 
> If we use -dumpdir as a prefix to dump names, as we historically have,
> if it doesn't end with a slash (or any dir separator) then it could be
> used to specify the prefix for multiple outputs, as in the above.  So
> gcc -dumpdir foobar- foo.c bar.c -o foobar *could* be equivalent to the
> above.  I.e., an executable output name would affect the -dumpdir, but
> not the -dumpbase passed to the compiler, whereas -dumpbase would be
> derived from an asm or obj output or from input.
> 
> In the end, they're pasted together one way or the other, the difference
> is the ability to override one or the other.  E.g.,
> 
>   gcc -dumpbase foobar foo.c bar.c -c
> 
> could then be rejected, just as -o foo+bar.o would be, or foobar could
> be appended to the implicit -dumpdir and then override -dumpbase to
> foo.c or bar.c in each compilation, to get foobar-foo.o and foobar-bar.o
> outputs, getting the same as:
> 
>   gcc -dumpdir foobar- foo.c bar.c -c
> 
> and then
> 
>   gcc -dumpdir temp/foobar- foo.c bar.c -o foo+bar -save-temps
> 
> would still create and preserve .o (and .i and .s) named after
> foobar-foo and foobar-bar within temp, rather than foo+bar-foo and
> foo+bar-bar.

Hum.  I didn't notice -dumpdir is just a prefix and I wouldn't object
to make it errorneous if it doesn't specify an acutal directory.

I also note that neither -dumpdir nor -dumpbase are documented
in invoke.texi (as opposed to -auxbase and -auxbase-strip which
are not user-accessible as they are rejected by the driver).
Not sure if all this means we should document the altered behavior
or if we should take it as a hint we can alter behavior at will
(in future) ;)

> Now, t

Re: introduce -fcallgraph-info option

[Alexandre Oliva]

On Nov 14, 2019, Alexandre Oliva  wrote:

> In order to address this, I propose we add an internal option (not for
> the driver), -dumpbase-ext, that names the extension to be discarded
> from dumpbase to form aux output names.

Here's a WIP patch that implements much of the desired semantics.

I'm still struggling a bit with -gdwarf-split and -save-temps; -dumpbase
and multiple inputs, -dumpdir as a prefix, and -flto + -dump*.

-gdwarf-split uses %b to strip debug info into the .dwo file, so it
lands in the same location as the .o, rather than in a named -dumpdir as
specified in the .o debug info skeleton.  I'm thinking of arranging for
-dump* flags to affect %b and %B, just like -save-temps does.  I've
reviewed all uses of %b and %B, and it looks like this would enable us
to fix the .dwo naming mismatch without significant complication.

Which brings us to the next issue.  This would cause -dumpdir to
override the -save-temps location.  This is arguably an improvement.  It
might conflict with -save-temps=cwd, however.

I'm considering rejecting command lines that specify both an explicit
-dumpdir and -save-temps=cwd, and in the absence of an explicit
-dumpdir, arranging for -save-temps=cwd or -save-temps=obj to override
what would otherwise be the default -dumpdir.

Or, for the sake of simplifying and bringing more sanity to the logic of
naming extra output files, we could just discontinue -save-temps=*, and
require -dumpdir ./ along with plain -save-temps to get the effects of
-save-temps=cwd.


When compiling multiple inputs with a single -dumpbase, the current
implementation arranges for each compilation to take an adjusted
-dumpbase appending - to the given dumpbase, minus extension.  An
alternative would be to reject such compilations, just as we reject
multiple compilations with a single object file named as output.  That
feels excessive for -dumpbase, however.  OTOH, adjusting -dumpbase only
when there are multiple inputs causes different behavior comparing:

  gcc -c foo.c -dumpbase foobar && gcc -c bar.c -dumpbase foobar

and

  gcc -c foo.c bar.c -dumpbase foobar

The latter will name outputs after foobar-foo and foobar-bar,
respectively, whereas the former will overwrite outputs named foobar
when compiling bar.c.  Under the proposal to modify %b according to
-dump*, even object files would be named after an explicit -dumpbase,
when -o is not explicitly specified.


Yet another thing I'm not so sure about is -dumpdir as a prefix, e.g.,
in cases we're compiling multiple files and then linking them together,
say 'gcc foo.c bar.c -o foobar', the proposal was to name dumps of the
compilations after foobar-foo and foobar-bar, respectively.

If we use -dumpdir as a prefix to dump names, as we historically have,
if it doesn't end with a slash (or any dir separator) then it could be
used to specify the prefix for multiple outputs, as in the above.  So
gcc -dumpdir foobar- foo.c bar.c -o foobar *could* be equivalent to the
above.  I.e., an executable output name would affect the -dumpdir, but
not the -dumpbase passed to the compiler, whereas -dumpbase would be
derived from an asm or obj output or from input.

In the end, they're pasted together one way or the other, the difference
is the ability to override one or the other.  E.g.,

  gcc -dumpbase foobar foo.c bar.c -c

could then be rejected, just as -o foo+bar.o would be, or foobar could
be appended to the implicit -dumpdir and then override -dumpbase to
foo.c or bar.c in each compilation, to get foobar-foo.o and foobar-bar.o
outputs, getting the same as:

  gcc -dumpdir foobar- foo.c bar.c -c

and then

  gcc -dumpdir temp/foobar- foo.c bar.c -o foo+bar -save-temps

would still create and preserve .o (and .i and .s) named after
foobar-foo and foobar-bar within temp, rather than foo+bar-foo and
foo+bar-bar.

Now, the implementation in the patch below places the link output name,
implicit or not, in the default -dumpbase rather than -dumpdir, so the
last command above would create temp/foobar-foo+bar-foo.o and
temp/foobar-foo+bar-bar.o.  It's this ability to override the
executable-name prefix we're adding to outputs separately from -dumpbase
that I find somewhat appealing, in that it enables even the effect of
such prefixing to be canceled out with e.g. -dumpdir ./

Any thoughts for or against (or requests for clarification on :-) any of
the above proposed changes?


As for -flto + -dump*, the problem is that lto-wrapper doesn't take any
-dump* flags into account, it just overrides them all as if none had
been specified, which is undesirable.  That's fixable, it's just that
I haven't got to it yet.

I haven't brought in the design/documentation into a .texi file yet.
Please refer to posts upthread for the proposal.


Here's the WIP patch, FTR:

---
 gcc/ada/gcc-interface/lang-specs.h |7 +
 gcc/ada/switch.adb |4 -
 gcc/common.opt |   19 ++-
 gcc/dwarf2out.c|3 -
 gcc/fortran/options.c 

Re: introduce -fcallgraph-info option

[Richard Biener]

On Wed, 20 Nov 2019, Alexandre Oliva wrote:

> On Nov  6, 2019, Alexandre Oliva  wrote:
> 
> > (CALLEE_FROM_CGRAPH_P): New.
> > (dump_final_callee_vcg, dump_final_node_vcg): New.
> 
> I goofed in the testing of this last-minute change.  It only works with
> optimization disabled.  With any optimization enabled,
> pass_remove_cgraph_callee_edges runs first thing in
> pass_all_optimizations{,_g} without a subsequent
> pass_rebuild_cgraph_edges.  This release takes place long before we'd
> even know which calls make to expand, and thus to the callgraph-info
> expected output.
> 
> It has just occurred to me that I could retain the logic but make it
> conditional on !optimize, but that would be error prone (AFAICT there's
> no reason why we don't release callees early without optimization) and
> probably not worth it.
> 
> 
> drop attempt to reuse cgraph callees for -fcallgraph-info
> 
> The information in cgraph callees is released long before we get to
> the point in which -fcallgraph-info edges are dumped, or even
> expanded.  It doesn't make sense to retain it longer: the edges
> created for -fcallgraph-info are much smaller, and they don't even
> coexist, so not even peak use grows.
> 
> Regstrapped on x86_64-linux-gnu.  Ok to install?

OK.

Richard.

> 
> for  gcc/ChangeLog
> 
>   * function.h (CALLEE_FROM_CGRAPH_P): Remove.
>   * function.c (record_final_call): Record even calls that might
>   have been in the cgraph.
>   * toplev.c (dump_final_node_vcg): Skip iteration over cgraph
>   callees.
> ---
>  gcc/function.c |3 ---
>  gcc/function.h |5 +
>  gcc/toplev.c   |8 
>  3 files changed, 1 insertion(+), 15 deletions(-)
> 
> diff --git a/gcc/function.c b/gcc/function.c
> index 1fe956b..2534c92 100644
> --- a/gcc/function.c
> +++ b/gcc/function.c
> @@ -6406,9 +6406,6 @@ rest_of_handle_thread_prologue_and_epilogue (void)
>  void
>  record_final_call (tree callee, location_t location)
>  {
> -  if (!callee || CALLEE_FROM_CGRAPH_P (callee))
> -return;
> -
>struct callinfo_callee datum = { location, callee };
>vec_safe_push (cfun->su->callees, datum);
>  }
> diff --git a/gcc/function.h b/gcc/function.h
> index 14794c4..beb5c7d 100644
> --- a/gcc/function.h
> +++ b/gcc/function.h
> @@ -192,15 +192,12 @@ public:
>poly_int64 length;
>  };
>  
> -/* Describe emitted builtin calls for -fcallgraph-info.  Those that
> -   are not builtin are taken from cgraph edges.  */
> +/* Describe emitted calls for -fcallgraph-info.  */
>  struct GTY(()) callinfo_callee
>  {
>location_t location;
>tree decl;
>  };
> -#define CALLEE_FROM_CGRAPH_P(T)  \
> -  (!fndecl_built_in_p (T) && !DECL_IS_BUILTIN (T))
>  
>  /* Describe dynamic allocation for -fcallgraph-info=da.  */
>  struct GTY(()) callinfo_dalloc
> diff --git a/gcc/toplev.c b/gcc/toplev.c
> index d4583ba..3b9f9ee 100644
> --- a/gcc/toplev.c
> +++ b/gcc/toplev.c
> @@ -1093,14 +1093,6 @@ dump_final_node_vcg (FILE *f)
>  dump_final_callee_vcg (f, c->location, c->decl);
>vec_free (cfun->su->callees);
>cfun->su->callees = NULL;
> -
> -  cgraph_node *cnode = cgraph_node::get (current_function_decl);
> -  for (cgraph_edge *e = cnode->callees; e; e = e->next_callee)
> -if (CALLEE_FROM_CGRAPH_P (e->callee->decl))
> -  dump_final_callee_vcg (f, gimple_location (e->call_stmt),
> -  e->callee->decl);
> -  for (cgraph_edge *e = cnode->indirect_calls; e; e = e->next_callee)
> -dump_final_callee_vcg (f, gimple_location (e->call_stmt), NULL);
>  }
>  
>  /* Output stack usage and callgraph info, as requested.  */
> 
> 
> 
> 
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)

Re: introduce -fcallgraph-info option

[Alexandre Oliva]

On Nov  6, 2019, Alexandre Oliva  wrote:

>   (CALLEE_FROM_CGRAPH_P): New.
>   (dump_final_callee_vcg, dump_final_node_vcg): New.

I goofed in the testing of this last-minute change.  It only works with
optimization disabled.  With any optimization enabled,
pass_remove_cgraph_callee_edges runs first thing in
pass_all_optimizations{,_g} without a subsequent
pass_rebuild_cgraph_edges.  This release takes place long before we'd
even know which calls make to expand, and thus to the callgraph-info
expected output.

It has just occurred to me that I could retain the logic but make it
conditional on !optimize, but that would be error prone (AFAICT there's
no reason why we don't release callees early without optimization) and
probably not worth it.


drop attempt to reuse cgraph callees for -fcallgraph-info

The information in cgraph callees is released long before we get to
the point in which -fcallgraph-info edges are dumped, or even
expanded.  It doesn't make sense to retain it longer: the edges
created for -fcallgraph-info are much smaller, and they don't even
coexist, so not even peak use grows.

Regstrapped on x86_64-linux-gnu.  Ok to install?


for  gcc/ChangeLog

* function.h (CALLEE_FROM_CGRAPH_P): Remove.
* function.c (record_final_call): Record even calls that might
have been in the cgraph.
* toplev.c (dump_final_node_vcg): Skip iteration over cgraph
callees.
---
 gcc/function.c |3 ---
 gcc/function.h |5 +
 gcc/toplev.c   |8 
 3 files changed, 1 insertion(+), 15 deletions(-)

diff --git a/gcc/function.c b/gcc/function.c
index 1fe956b..2534c92 100644
--- a/gcc/function.c
+++ b/gcc/function.c
@@ -6406,9 +6406,6 @@ rest_of_handle_thread_prologue_and_epilogue (void)
 void
 record_final_call (tree callee, location_t location)
 {
-  if (!callee || CALLEE_FROM_CGRAPH_P (callee))
-return;
-
   struct callinfo_callee datum = { location, callee };
   vec_safe_push (cfun->su->callees, datum);
 }
diff --git a/gcc/function.h b/gcc/function.h
index 14794c4..beb5c7d 100644
--- a/gcc/function.h
+++ b/gcc/function.h
@@ -192,15 +192,12 @@ public:
   poly_int64 length;
 };
 
-/* Describe emitted builtin calls for -fcallgraph-info.  Those that
-   are not builtin are taken from cgraph edges.  */
+/* Describe emitted calls for -fcallgraph-info.  */
 struct GTY(()) callinfo_callee
 {
   location_t location;
   tree decl;
 };
-#define CALLEE_FROM_CGRAPH_P(T)\
-  (!fndecl_built_in_p (T) && !DECL_IS_BUILTIN (T))
 
 /* Describe dynamic allocation for -fcallgraph-info=da.  */
 struct GTY(()) callinfo_dalloc
diff --git a/gcc/toplev.c b/gcc/toplev.c
index d4583ba..3b9f9ee 100644
--- a/gcc/toplev.c
+++ b/gcc/toplev.c
@@ -1093,14 +1093,6 @@ dump_final_node_vcg (FILE *f)
 dump_final_callee_vcg (f, c->location, c->decl);
   vec_free (cfun->su->callees);
   cfun->su->callees = NULL;
-
-  cgraph_node *cnode = cgraph_node::get (current_function_decl);
-  for (cgraph_edge *e = cnode->callees; e; e = e->next_callee)
-if (CALLEE_FROM_CGRAPH_P (e->callee->decl))
-  dump_final_callee_vcg (f, gimple_location (e->call_stmt),
-e->callee->decl);
-  for (cgraph_edge *e = cnode->indirect_calls; e; e = e->next_callee)
-dump_final_callee_vcg (f, gimple_location (e->call_stmt), NULL);
 }
 
 /* Output stack usage and callgraph info, as requested.  */




-- 
Alexandre Oliva, freedom fighter   he/him   https://FSFLA.org/blogs/lxo
Free Software Evangelist   Stallman was right, but he's left :(
GNU Toolchain EngineerFSMatrix: It was he who freed the first of us
FSF & FSFLA board memberThe Savior shall return (true);

Re: introduce -fcallgraph-info option

[Alexandre Oliva]

On Nov 15, 2019, Richard Biener  wrote:

> Hmm, -dwo-base-name to the rescue? ;)

I'd rather have less rather than more complexity.  I.e., make the
objcopy command match the dumpdir location, that defaults to the output
location.  The more such options we have, the harder it is to document,
understand, and implement correctly.

> so all that is needed is to keep that consistent?

*nod*

-- 
Alexandre Oliva, freedom fighter   he/him   https://FSFLA.org/blogs/lxo
Free Software Evangelist   Stallman was right, but he's left :(
GNU Toolchain EngineerFSMatrix: It was he who freed the first of us
FSF & FSFLA board memberThe Savior shall return (true);

Re: introduce -fcallgraph-info option

[Richard Biener]

On Fri, 15 Nov 2019, Alexandre Oliva wrote:

> On Nov 14, 2019, Alexandre Oliva  wrote:
> 
> > %{!c:%{!S:-dumpbase %b}
> 
> Uhh, I failed to adjust this one to add the executable output name to
> dumpbase.
> 
> Anyway, getting the right semantics out of specs is providing to be a
> lot trickier than I had anticipated.  I'm now pondering a single spec
> function to deal with all of these dumpbase possibilities.
> 
> I'm also a little uncertain about behavior change WRT .dwo files.
> Though their names are built out of the .o files in the objcopy
> commands, they're built from aux_base_name in dwarf2out.  Currently,
> since aux_base_name is derived from the output object file name, this
> ensures they have the same name and directory, but once we enable
> -dumpdir to be specified to override it, that may no longer be the
> case.  Ugh...

Hmm, -dwo-base-name to the rescue? ;)  Well, I guess the debug info
has to somewhere encode the full/relative path to the .dwo files
so all that is needed is to keep that consistent?

Richard.

Re: introduce -fcallgraph-info option

[Alexandre Oliva]

On Nov 14, 2019, Alexandre Oliva  wrote:

> %{!c:%{!S:-dumpbase %b}

Uhh, I failed to adjust this one to add the executable output name to
dumpbase.

Anyway, getting the right semantics out of specs is providing to be a
lot trickier than I had anticipated.  I'm now pondering a single spec
function to deal with all of these dumpbase possibilities.

I'm also a little uncertain about behavior change WRT .dwo files.
Though their names are built out of the .o files in the objcopy
commands, they're built from aux_base_name in dwarf2out.  Currently,
since aux_base_name is derived from the output object file name, this
ensures they have the same name and directory, but once we enable
-dumpdir to be specified to override it, that may no longer be the
case.  Ugh...

-- 
Alexandre Oliva, freedom fighter   he/him   https://FSFLA.org/blogs/lxo
Free Software Evangelist   Stallman was right, but he's left :(
GNU Toolchain EngineerFSMatrix: It was he who freed the first of us
FSF & FSFLA board memberThe Savior shall return (true);

Re: introduce -fcallgraph-info option

[Alexandre Oliva]

On Nov  8, 2019, Eric Gallager  wrote:

> If you're touching the -auxbase option... is that related to the other
> options starting with -aux at all?

'fraid they're entirely unrelated.  We're talking about how the compiler
names aux and dump output files, which is not related with the contents
of an explicitly-named output file as the PR you mentioned.

-- 
Alexandre Oliva, freedom fighter   he/him   https://FSFLA.org/blogs/lxo
Free Software Evangelist   Stallman was right, but he's left :(
GNU Toolchain EngineerFSMatrix: It was he who freed the first of us
FSF & FSFLA board memberThe Savior shall return (true);

Re: introduce -fcallgraph-info option

[Alexandre Oliva]

On Nov  8, 2019, Richard Biener  wrote:

> Wow, thanks for the elaborate write-up!  I wonder if we can
> cut&paste this into documentation somewhere appropriate, maybe
> there's already a section for "auxiliary compiler outputs".

Sure, that makes sense.

>> I'm a little hesitant, this amounts to quite significant behavior
>> changes.  Do these seem acceptable and desirable nevertheless?

> I think the current state is somewhat of a mess and in some
> cases confusing and your suggestion sounds like an overall
> improvement to me (you didn't actually suggest to remove
> either of the -dump{base,dir} -auxbase{-strip} options?)

I was trying to narrow down the desired behavior before trying to figure
out what options we could do away with.  If what I proposed was
acceptable, I thought we could drop the internal -auxbase* options
altogether.

However, I missed one relevant case in my analysis.  I suggested the
auxbase internally derived from dumpbase would drop the dumpbase
extension iff the extension matched that of the input file name.  That
doesn't work when compilation takes an intermediate file rather than the
input, e.g., in a -save-temps compilation, in which we'll have separate
preprocessing and the actual compiler will take the saved preprocessed
input, but should still output dumps to files named after the .c input.

ex $CC -S srcdir/foo.c -o objdir/foo.s -save-temps
-> objdir/foo.i objdir/foo.s objdir/foo.su objdir/foo.c.#t.original

The compilation line would only take the .c from -dumpbase, but since
its input is .i, it wouldn't match, and we wouldn't strip the .c from
aux outputs, and would instead generate:

-> objdir/foo.i objdir/foo.s objdir/foo.c.su objdir/foo.c.#t.original
   ^^

(which would likely be ok for .su, but quite unexpected for .dwo)

In order to address this, I propose we add an internal option (not for
the driver), -dumpbase-ext, that names the extension to be discarded
from dumpbase to form aux output names.

-dumpdir objdir -dumpbase foo.c -dumpbase-ext .c

The new -dumpbase-ext option specifies the extension to drop from the
specified -dumpbase to form aux output names, but dump output names keep
that intermediate extension.  When absent, we take it from the main
input file.

So aux outputs end up as objdir/foo.* whereas dump outputs end up as
objdump/foo.c.*, just as expected.

We could keep -dumpbase-ext an internal option, used only when doing
separate preprocessing, but it might make sense to expose it for use
along with -dumpbase for such tools as ccache and distcc, that call the
compiler driver with internal .i files, but would still prefer dumps and
aux files to be generated just as they would have for the .c files.

Specs would change from:

%{!dumpbase:-dumpbase %B}
%{c|S:%{o*:-auxbase-strip %*}
  %{!o*:-auxbase %b}}}
%{!c:%{!S:-auxbase %b}

to

%{!dumpdir:%{o*:-dumpdir %:dirname(%*)}}
%{c|S:%{!dumpbase:%{o*:-dumpbase %:replace-extension(%:basename(%*) 
%:extension(%i))}
  %{!o*:-dumpbase %b}}}
%{!c:%{!S:-dumpbase %b}

and add to separate preprocessing commands:

%{!dumpbase-ext:-dumpbase-ext %:extension(%i)}


Then we'd set up aux_base_name from dump_base_name minus the extension,
given or taken from main_input_filename.

-- 
Alexandre Oliva, freedom fighter   he/him   https://FSFLA.org/blogs/lxo
Free Software Evangelist   Stallman was right, but he's left :(
GNU Toolchain EngineerFSMatrix: It was he who freed the first of us
FSF & FSFLA board memberThe Savior shall return (true);

Re: introduce -fcallgraph-info option

[Eric Gallager]

On 11/8/19, Richard Biener  wrote:
> On Thu, 7 Nov 2019, Alexandre Oliva wrote:
>
>> On Nov  7, 2019, Richard Biener  wrote:
>>
>> > (also raises the question why we have both -dumpbase and -auxbase ...)
>>
>> https://gcc.gnu.org/ml/gcc-patches/2002-08/msg00294.html
>>
>> This was before -dumpdir, however.
>>
>> Here's the current logic for aux_base_name:
>>
>> -c or -S with -o [odir/]obase.oext: [odir/]obase
>> otherwise, given input [idir/]ibase.iext: ibase
>>
>> Whereas the current logic for dump_base_name, once aux_base_name has
>> been determined as [auxdir/]auxbase, is:
>>
>> given -dumpbase ddir/dbase: ddir/dbase
>> otherwise, given -dumpdir ddir and -dumpbase dbase: ddir/dbase
>> otherwise, given -dumpbase dbase: [auxdir/]dbase
>> otherwise, given -dumpdir ddir: ddir/ibase.iext
>> otherwise: [auxdir/]ibase.iext
>>
>> Relevant cases to consider: (aux, dump) for each compilation with
>> CC='gcc -fstack-usage -fdump-tree-original'
>>
>> compiling without -o: (ibase, ibase.iext)
>> ex $CC -c srcdir/foo.c srcdir/x/bar.c
>> -> foo.o foo.su foo.c.#t.original
>>  + bar.o bar.su bar.c.#t.original
>>
>> compiling with -o: ([odir/]obase, [odir/]ibase.iext)
>> ex $CC -c srcdir/foo.c -o objdir/foobaz.o -Dfoobaz
>> -> objdir/foobaz.o objdir/foobaz.su objdir/foo.c.#t.original
>>
>> compiling multiple sources with -dumpbase: (ibase, [ddir/]dbase)
>> ex $CC -dumpbase outdir/runme.dump -c srcdir/foo.c srcdir/x/bar.c
>> -> foo.o foo.su outdir/runme.dump.#t.original
>>  + bar.o bar.su outdir/runme.dump.#t.original (dupe)
>>
>> compiling and linking with -o: (ibase, ibase.iext)
>> ex $CC -o outdir/runme srcdir/foo.c srcdir/x/bar.c
>> -> /tmp/temp().o foo.su foo.c.#t.original
>>  + /tmp/temp().o bar.su bar.c.#t.original
>>  + outdir/runme
>>
>> lto-recompiling and linking with -o: (/tmp/obase.temp().ltrans#.ltrans,
>> odir/obase.ltrans#)
>> ex $CC -o outdir/runme ltobjdir/foo.o ltobjdir/bar.o -fdump-rtl-expand
>> -> /tmp/runme.temp().ltrans0.ltrans.o /tmp/runme.temp().ltrans0.ltrans.su
>>  + outdir/runme.ltrans0.#r.expand
>>  + outdir/runme
>>
>> lto-recompiling and linking without -o: (/tmp/temp().ltrans#.ltrans,
>> /tmp/temp().ltrans#.o)
>> ex $CC ltobjdir/foo.o ltobjdir/bar.o -fdump-rtl-expand
>> -> /tmp/temp().ltrans0.ltrans.o /tmp/temp().ltrans0.ltrans.su
>>  + /tmp/temp().ltrans0.#r.expand
>>  + a.out
>>
>>
>> If we were to unify auxbase and dumpbase, I'd take the opportunity to
>> fix the -o objdir/foobaz.o compilation to output dumps named after
>> objdir/foobaz or objdir/foobaz-foo.c rather than ./foo.c; for
>> outdir/runme.dump to be used as a prefix for aux and dump names, so that
>> we wouldn't create and then overwrite outdir/runme.dump, and so that
>> other compilations of foo.c and bar.c wouldn't overwrite the .su files,
>> but rather create outdir/runme.dump-{foo,bar}.* dumps and aux files; and
>> likewise use outdir/runme.ltrans0 or a.out.ltrans0 for the .su and
>> .expand files.
>>
>>
>> The logic I suggest is involves combining some of the -auxbase and some
>> of the -dumpbase logic, namely:
>>
>> In the driver:
>>
>> compiling a single source idir/ibase.iext:
>>
>>   -o odir/obase.oext specified: default -dumpdir odir -dumpbase
>> obase.iext
>>   -o obase.oext specified: default -dumpbase obase.iext
>>   -o ibase.oext implied: default -dumpbase ibase.iext
>>
>> compiling multiple sources named as ibase.iext for linking:
>>
>>   -dumpbase [ddir/]dbase specified: make it -dumpbase
>> [ddir/]dbase-ibase.iext
>>   -o odir/output specified: default -dumpdir odir -dumpbase
>> output-ibase.iext
>>   -o output specified: default -dumpbase output-ibase.iext
>>   -o a.out implied: default -dumpbase a.out-ibase.iext
>>
>> LTO recompiling:
>>
>>   same as above, with each ibase.iext set to ltrans#
>>
>>
>> In the compiler, set dump_base_name to:
>>
>> Given -dumpbase ddir/dbase: ddir/dbase
>> otherwise, given -dumpdir ddir and -dumpbase dbase: ddir/dbase
>> otherwise, given -dumpbase dbase: dbase
>>
>> and copy aux_base_name from dump_base_name, but if it ends in .iext,
>> drop the extension.
>>
>> The resulting behavior (aux_base_name, dump_base_name)
>>
>> compiling without -o: (ibase, ibase.iext)  unchanged
>> ex $CC -c srcdir/foo.c srcdir/x/bar.c
>> -> foo.o foo.su foo.c.#t.original
>>  + bar.o bar.su bar.c.#t.original
>>
>> compiling with -o: ([odir/]obase, [odir/]obase.iext)
>> ex $CC -c srcdir/foo.c -o objdir/foobaz.o -Dfoobaz
>> -> objdir/foobaz.o objdir/foobaz.su objdir/foobaz.c.#t.original
>>
>> compiling multiple sources with -dumpbase: ([ddir]/dbase, [ddir/]dbase)
>> ex $CC -dumpbase outdir/runme.dump -c srcdir/foo.c srcdir/x/bar.c
>> -> foo.o outdir/runme.dump-foo.su outdir/runme.dump-foo.c.#t.original
>>  + bar.o outdir/runme.dump-bar.su outdir/runme.dump-bar.c.#t.original
>>
>> compiling and linking with -o: (outdir/runme-ibase,
>> outdir/runme-ibase.iext)
>> ex $CC -o outdir/runme srcdir/foo.c srcdir/x/bar.c
>> -> /tmp/temp().o outdir/runme-foo.su outdir/runme-foo.c.#t.original
>>  + /tmp/temp().

Re: introduce -fcallgraph-info option

[Richard Biener]

On Thu, 7 Nov 2019, Alexandre Oliva wrote:

> On Nov  7, 2019, Richard Biener  wrote:
> 
> > (also raises the question why we have both -dumpbase and -auxbase ...)
> 
> https://gcc.gnu.org/ml/gcc-patches/2002-08/msg00294.html
> 
> This was before -dumpdir, however.
> 
> Here's the current logic for aux_base_name:
> 
> -c or -S with -o [odir/]obase.oext: [odir/]obase
> otherwise, given input [idir/]ibase.iext: ibase
> 
> Whereas the current logic for dump_base_name, once aux_base_name has
> been determined as [auxdir/]auxbase, is:
> 
> given -dumpbase ddir/dbase: ddir/dbase
> otherwise, given -dumpdir ddir and -dumpbase dbase: ddir/dbase
> otherwise, given -dumpbase dbase: [auxdir/]dbase
> otherwise, given -dumpdir ddir: ddir/ibase.iext
> otherwise: [auxdir/]ibase.iext
> 
> Relevant cases to consider: (aux, dump) for each compilation with
> CC='gcc -fstack-usage -fdump-tree-original'
> 
> compiling without -o: (ibase, ibase.iext)
> ex $CC -c srcdir/foo.c srcdir/x/bar.c
> -> foo.o foo.su foo.c.#t.original
>  + bar.o bar.su bar.c.#t.original
> 
> compiling with -o: ([odir/]obase, [odir/]ibase.iext)
> ex $CC -c srcdir/foo.c -o objdir/foobaz.o -Dfoobaz
> -> objdir/foobaz.o objdir/foobaz.su objdir/foo.c.#t.original
> 
> compiling multiple sources with -dumpbase: (ibase, [ddir/]dbase)
> ex $CC -dumpbase outdir/runme.dump -c srcdir/foo.c srcdir/x/bar.c
> -> foo.o foo.su outdir/runme.dump.#t.original
>  + bar.o bar.su outdir/runme.dump.#t.original (dupe)
> 
> compiling and linking with -o: (ibase, ibase.iext)
> ex $CC -o outdir/runme srcdir/foo.c srcdir/x/bar.c
> -> /tmp/temp().o foo.su foo.c.#t.original
>  + /tmp/temp().o bar.su bar.c.#t.original
>  + outdir/runme
> 
> lto-recompiling and linking with -o: (/tmp/obase.temp().ltrans#.ltrans, 
> odir/obase.ltrans#)
> ex $CC -o outdir/runme ltobjdir/foo.o ltobjdir/bar.o -fdump-rtl-expand
> -> /tmp/runme.temp().ltrans0.ltrans.o /tmp/runme.temp().ltrans0.ltrans.su
>  + outdir/runme.ltrans0.#r.expand
>  + outdir/runme
> 
> lto-recompiling and linking without -o: (/tmp/temp().ltrans#.ltrans, 
> /tmp/temp().ltrans#.o)
> ex $CC ltobjdir/foo.o ltobjdir/bar.o -fdump-rtl-expand
> -> /tmp/temp().ltrans0.ltrans.o /tmp/temp().ltrans0.ltrans.su
>  + /tmp/temp().ltrans0.#r.expand
>  + a.out
> 
> 
> If we were to unify auxbase and dumpbase, I'd take the opportunity to
> fix the -o objdir/foobaz.o compilation to output dumps named after
> objdir/foobaz or objdir/foobaz-foo.c rather than ./foo.c; for
> outdir/runme.dump to be used as a prefix for aux and dump names, so that
> we wouldn't create and then overwrite outdir/runme.dump, and so that
> other compilations of foo.c and bar.c wouldn't overwrite the .su files,
> but rather create outdir/runme.dump-{foo,bar}.* dumps and aux files; and
> likewise use outdir/runme.ltrans0 or a.out.ltrans0 for the .su and
> .expand files.
> 
> 
> The logic I suggest is involves combining some of the -auxbase and some
> of the -dumpbase logic, namely:
> 
> In the driver:
> 
> compiling a single source idir/ibase.iext:
> 
>   -o odir/obase.oext specified: default -dumpdir odir -dumpbase obase.iext
>   -o obase.oext specified: default -dumpbase obase.iext
>   -o ibase.oext implied: default -dumpbase ibase.iext
> 
> compiling multiple sources named as ibase.iext for linking:
> 
>   -dumpbase [ddir/]dbase specified: make it -dumpbase [ddir/]dbase-ibase.iext
>   -o odir/output specified: default -dumpdir odir -dumpbase output-ibase.iext
>   -o output specified: default -dumpbase output-ibase.iext
>   -o a.out implied: default -dumpbase a.out-ibase.iext
> 
> LTO recompiling:
> 
>   same as above, with each ibase.iext set to ltrans#
> 
> 
> In the compiler, set dump_base_name to:
> 
> Given -dumpbase ddir/dbase: ddir/dbase
> otherwise, given -dumpdir ddir and -dumpbase dbase: ddir/dbase
> otherwise, given -dumpbase dbase: dbase
> 
> and copy aux_base_name from dump_base_name, but if it ends in .iext,
> drop the extension.
> 
> The resulting behavior (aux_base_name, dump_base_name)
> 
> compiling without -o: (ibase, ibase.iext)  unchanged
> ex $CC -c srcdir/foo.c srcdir/x/bar.c
> -> foo.o foo.su foo.c.#t.original
>  + bar.o bar.su bar.c.#t.original
> 
> compiling with -o: ([odir/]obase, [odir/]obase.iext)
> ex $CC -c srcdir/foo.c -o objdir/foobaz.o -Dfoobaz
> -> objdir/foobaz.o objdir/foobaz.su objdir/foobaz.c.#t.original
> 
> compiling multiple sources with -dumpbase: ([ddir]/dbase, [ddir/]dbase)
> ex $CC -dumpbase outdir/runme.dump -c srcdir/foo.c srcdir/x/bar.c
> -> foo.o outdir/runme.dump-foo.su outdir/runme.dump-foo.c.#t.original
>  + bar.o outdir/runme.dump-bar.su outdir/runme.dump-bar.c.#t.original
> 
> compiling and linking with -o: (outdir/runme-ibase, outdir/runme-ibase.iext)
> ex $CC -o outdir/runme srcdir/foo.c srcdir/x/bar.c
> -> /tmp/temp().o outdir/runme-foo.su outdir/runme-foo.c.#t.original
>  + /tmp/temp().o outdir/runme-bar.su outdir/runme-bar.c.#t.original
>  + outdir/runme
> 
> lto-recompiling and linking with -o: (outdir/runme.ltrans#, 

Re: introduce -fcallgraph-info option

[Alexandre Oliva]

On Nov  7, 2019, Richard Biener  wrote:

> (also raises the question why we have both -dumpbase and -auxbase ...)

https://gcc.gnu.org/ml/gcc-patches/2002-08/msg00294.html

This was before -dumpdir, however.

Here's the current logic for aux_base_name:

-c or -S with -o [odir/]obase.oext: [odir/]obase
otherwise, given input [idir/]ibase.iext: ibase

Whereas the current logic for dump_base_name, once aux_base_name has
been determined as [auxdir/]auxbase, is:

given -dumpbase ddir/dbase: ddir/dbase
otherwise, given -dumpdir ddir and -dumpbase dbase: ddir/dbase
otherwise, given -dumpbase dbase: [auxdir/]dbase
otherwise, given -dumpdir ddir: ddir/ibase.iext
otherwise: [auxdir/]ibase.iext

Relevant cases to consider: (aux, dump) for each compilation with
CC='gcc -fstack-usage -fdump-tree-original'

compiling without -o: (ibase, ibase.iext)
ex $CC -c srcdir/foo.c srcdir/x/bar.c
-> foo.o foo.su foo.c.#t.original
 + bar.o bar.su bar.c.#t.original

compiling with -o: ([odir/]obase, [odir/]ibase.iext)
ex $CC -c srcdir/foo.c -o objdir/foobaz.o -Dfoobaz
-> objdir/foobaz.o objdir/foobaz.su objdir/foo.c.#t.original

compiling multiple sources with -dumpbase: (ibase, [ddir/]dbase)
ex $CC -dumpbase outdir/runme.dump -c srcdir/foo.c srcdir/x/bar.c
-> foo.o foo.su outdir/runme.dump.#t.original
 + bar.o bar.su outdir/runme.dump.#t.original (dupe)

compiling and linking with -o: (ibase, ibase.iext)
ex $CC -o outdir/runme srcdir/foo.c srcdir/x/bar.c
-> /tmp/temp().o foo.su foo.c.#t.original
 + /tmp/temp().o bar.su bar.c.#t.original
 + outdir/runme

lto-recompiling and linking with -o: (/tmp/obase.temp().ltrans#.ltrans, 
odir/obase.ltrans#)
ex $CC -o outdir/runme ltobjdir/foo.o ltobjdir/bar.o -fdump-rtl-expand
-> /tmp/runme.temp().ltrans0.ltrans.o /tmp/runme.temp().ltrans0.ltrans.su
 + outdir/runme.ltrans0.#r.expand
 + outdir/runme

lto-recompiling and linking without -o: (/tmp/temp().ltrans#.ltrans, 
/tmp/temp().ltrans#.o)
ex $CC ltobjdir/foo.o ltobjdir/bar.o -fdump-rtl-expand
-> /tmp/temp().ltrans0.ltrans.o /tmp/temp().ltrans0.ltrans.su
 + /tmp/temp().ltrans0.#r.expand
 + a.out


If we were to unify auxbase and dumpbase, I'd take the opportunity to
fix the -o objdir/foobaz.o compilation to output dumps named after
objdir/foobaz or objdir/foobaz-foo.c rather than ./foo.c; for
outdir/runme.dump to be used as a prefix for aux and dump names, so that
we wouldn't create and then overwrite outdir/runme.dump, and so that
other compilations of foo.c and bar.c wouldn't overwrite the .su files,
but rather create outdir/runme.dump-{foo,bar}.* dumps and aux files; and
likewise use outdir/runme.ltrans0 or a.out.ltrans0 for the .su and
.expand files.


The logic I suggest is involves combining some of the -auxbase and some
of the -dumpbase logic, namely:

In the driver:

compiling a single source idir/ibase.iext:

  -o odir/obase.oext specified: default -dumpdir odir -dumpbase obase.iext
  -o obase.oext specified: default -dumpbase obase.iext
  -o ibase.oext implied: default -dumpbase ibase.iext

compiling multiple sources named as ibase.iext for linking:

  -dumpbase [ddir/]dbase specified: make it -dumpbase [ddir/]dbase-ibase.iext
  -o odir/output specified: default -dumpdir odir -dumpbase output-ibase.iext
  -o output specified: default -dumpbase output-ibase.iext
  -o a.out implied: default -dumpbase a.out-ibase.iext

LTO recompiling:

  same as above, with each ibase.iext set to ltrans#


In the compiler, set dump_base_name to:

Given -dumpbase ddir/dbase: ddir/dbase
otherwise, given -dumpdir ddir and -dumpbase dbase: ddir/dbase
otherwise, given -dumpbase dbase: dbase

and copy aux_base_name from dump_base_name, but if it ends in .iext,
drop the extension.

The resulting behavior (aux_base_name, dump_base_name)

compiling without -o: (ibase, ibase.iext)  unchanged
ex $CC -c srcdir/foo.c srcdir/x/bar.c
-> foo.o foo.su foo.c.#t.original
 + bar.o bar.su bar.c.#t.original

compiling with -o: ([odir/]obase, [odir/]obase.iext)
ex $CC -c srcdir/foo.c -o objdir/foobaz.o -Dfoobaz
-> objdir/foobaz.o objdir/foobaz.su objdir/foobaz.c.#t.original

compiling multiple sources with -dumpbase: ([ddir]/dbase, [ddir/]dbase)
ex $CC -dumpbase outdir/runme.dump -c srcdir/foo.c srcdir/x/bar.c
-> foo.o outdir/runme.dump-foo.su outdir/runme.dump-foo.c.#t.original
 + bar.o outdir/runme.dump-bar.su outdir/runme.dump-bar.c.#t.original

compiling and linking with -o: (outdir/runme-ibase, outdir/runme-ibase.iext)
ex $CC -o outdir/runme srcdir/foo.c srcdir/x/bar.c
-> /tmp/temp().o outdir/runme-foo.su outdir/runme-foo.c.#t.original
 + /tmp/temp().o outdir/runme-bar.su outdir/runme-bar.c.#t.original
 + outdir/runme

lto-recompiling and linking with -o: (outdir/runme.ltrans#, 
outdir/runme.ltrans#)
ex $CC -o outdir/runme ltobjdir/foo.o ltobjdir/bar.o -fdump-rtl-expand
-> /tmp/runme.temp().ltrans0.ltrans.o outdir/runme.ltrans0.su
 + outdir/runme.ltrans0.#r.expand
 + outdir/runme

lto-recompiling and linking without -o: (a.out.ltrans#, a.out.ltrans#)
ex $CC ltobjdir/foo

Re: introduce -fcallgraph-info option

[Richard Biener]

On Thu, 7 Nov 2019, Alexandre Oliva wrote:

> On Nov  7, 2019, Richard Biener  wrote:
> 
> > So how's -dumpbase handled?
> 
> It's part of the gcc driver interface, and lto-wrapper passes it to gcc
> for -fltrans compilations.  -auxbase isn't, so one of the alternatives I
> suggested involved our taking auxbase from dumpdir & dumpbase for
> -fltrans compilations.  The other alternatives amounted to exposing
> auxdir or auxbase in the driver interface, so that lto-wrapper could
> specify them explicitly.

Both variants sound reasonable to me (also raises the question why
we have both -dumpbase and -auxbase ...)

Richard.

Re: introduce -fcallgraph-info option

[Alexandre Oliva]

On Nov  7, 2019, Richard Biener  wrote:

> So how's -dumpbase handled?

It's part of the gcc driver interface, and lto-wrapper passes it to gcc
for -fltrans compilations.  -auxbase isn't, so one of the alternatives I
suggested involved our taking auxbase from dumpdir & dumpbase for
-fltrans compilations.  The other alternatives amounted to exposing
auxdir or auxbase in the driver interface, so that lto-wrapper could
specify them explicitly.

-- 
Alexandre Oliva, freedom fighter   he/him   https://FSFLA.org/blogs/lxo
Free Software Evangelist   Stallman was right, but he's left :(
GNU Toolchain EngineerFSMatrix: It was he who freed the first of us
FSF & FSFLA board memberThe Savior shall return (true);

Re: introduce -fcallgraph-info option

[Richard Biener]

On Thu, 7 Nov 2019, Alexandre Oliva wrote:

> On Nov  7, 2019, Richard Biener  wrote:
> 
> > A simple test shows we currently only pass -auxbase-strip /tmp/cc...o
> > to the LTRANS lto1 invocation plus -dumpbase cc...o
> 
> This -auxbase-strip argument is introduced by the gcc driver that runs
> lto1, based on the -o (tmp ltrans .o) argument, but this driver has no
> clue as to the executable name or location, and there's nothing
> whatsoever in the driver interface that enables aux_base_name to be
> located separately from the output name.  Thus the possibilities I
> brought up of introducing means for it to be told so, explicitly or by
> convention.

So how's -dumpbase handled?  I'd prefer the same approach for -auxbase

Richard.

Re: introduce -fcallgraph-info option

[Alexandre Oliva]

On Nov  6, 2019, Thomas Schwinge  wrote:

>> which is a valid VCG file (you can launch your favorite VCG
>> viewer on it unmodified)

> What should be my "favorite VCG viewer"?

-ENOCLUE, I'm afraid.  I honestly don't even know which one Eric used
back when he first attempted to contribute this feature, almost 10 years
ago.

What I do know is that visualization is not the primary goal.  There are
indeed newer and more elaborate and modern graph file formats for that.
The primary intended consumer of this output is gnatstack, that's long
used only this simple format.  It's hard to justify rewriting it and
creating an incompatibility when the simple format does the job well.

Plus, it's simple enough and regular enough that it should be quite easy
to parse it with a few lines of awk and post-process the .ci file into
any other graph format of interest, when visualization of the graph is
the aim.  If you show me examples of graph formats that you'd like, that
can represent all the data encoded in .ci files, it wouldn't take much
effort to persuade me to write the few lines of awk, or perhaps even
sed, to convert .ci files output by GCC to the other format ;-)


> I tried that, but 'xvcg' didn't render anything useful for a
> '-fcallgraph-info=su,da' dump, hmm.

Did xvcg fail to display the node information added by su and da?  As
in, do you see the difference the options make to the graph text file,
but not in the visualization?  Or is it something else?


> Also, I found that many years ago, in 2012, Steven Bosscher did "Rework
> RTL CFG graph dumping to dump DOT format" (that's Graphviz), and then did
> "remove vcg CFG dumper".

gnatstack and -fcallgraph-info have been available since long before
that move indeed.

> Note that I'm not actively objecting VCG

Good, thanks for pointing that out :-)

> unmaintained mid-90s software, containing obfuscated layout/rendering
> source code

Since gnatstack is the primary consumer, I think that objection doesn't
apply.


As a Free Software activist, however, I am a little concerned about the
claim about obfuscated source code.  I haven't been able to find any
substantiation of that in your message.  I think that would be OT for
this list, so would you please send me what you got about it at
ol...@fsf.org?  TIA,

-- 
Alexandre Oliva, freedom fighter   he/him   https://FSFLA.org/blogs/lxo
Free Software Evangelist   Stallman was right, but he's left :(
GNU Toolchain EngineerFSMatrix: It was he who freed the first of us
FSF & FSFLA board memberThe Savior shall return (true);

Re: introduce -fcallgraph-info option

[Alexandre Oliva]

On Nov  7, 2019, Richard Biener  wrote:

> A simple test shows we currently only pass -auxbase-strip /tmp/cc...o
> to the LTRANS lto1 invocation plus -dumpbase cc...o

This -auxbase-strip argument is introduced by the gcc driver that runs
lto1, based on the -o (tmp ltrans .o) argument, but this driver has no
clue as to the executable name or location, and there's nothing
whatsoever in the driver interface that enables aux_base_name to be
located separately from the output name.  Thus the possibilities I
brought up of introducing means for it to be told so, explicitly or by
convention.

-- 
Alexandre Oliva, freedom fighter   he/him   https://FSFLA.org/blogs/lxo
Free Software Evangelist   Stallman was right, but he's left :(
GNU Toolchain EngineerFSMatrix: It was he who freed the first of us
FSF & FSFLA board memberThe Savior shall return (true);

Re: introduce -fcallgraph-info option

[Richard Biener]

On Wed, 6 Nov 2019, Alexandre Oliva wrote:

> On Nov  4, 2019, Richard Biener  wrote:
> 
> > I wonder why we shouldn't simply adjust aux_base_name to something
> > else for -flto [in the driver].
> 
> About that, having tried to make sense of the current uses of
> aux_base_name and of lto-wrapper, three main possibilities occur to me:
> 
> a) adjust the driver code to accept -auxbase, and have lto-wrapper
> explicitly pass -aux-base ${output_dir-.}/$(lbasename ${output_name}) or
> somesuch for each -fltrans command;
> 
> b) introduce -auxdir and get lto-wrapper to pass -auxdir ${output_dir-.}
> for each -fltrans (and offload) command; or
> 
> c) get -fltrans to implicitly adjust aux_base_name with the directory
> passed to -dumpdir, if any, or . otherwise
>
> Any preferences?

A simple test shows we currently only pass -auxbase-strip /tmp/cc...o
to the LTRANS lto1 invocation plus -dumpbase cc...o
Even with -save-temps this doesn't "improve" unless you have an
explicit output via -o

So isn't one of the main issues that the naming of the auxiliar
files is based on some "temporary" file?  IMHO those should always
behave like if we passed -save-temps but I'm not sure how to achieve
that.  For example -dumpdir and -dumpbase seem to work like this
already so there must be code somewhere doing this and adjusting
-auxbase[-strip] to work the same way would make sense to me.

Doesn't really solve the case for "no output name given" (aka a.out
default) though - I suppose for dumping and auxiliar file naming
purpose we should simply assume -o a.out there?

Thanks,
Richard.

Re: introduce -fcallgraph-info option

[Thomas Schwinge]

Hi Alexandre!

On 2019-10-26T01:35:43-0300, Alexandre Oliva  wrote:
> This was first submitted many years ago
> https://gcc.gnu.org/ml/gcc-patches/2010-10/msg02468.html
>
> The command line option -fcallgraph-info is added and makes the
> compiler generate another output file (xxx.ci) for each compilation
> unit

Yay, for such analysis tools!  :-)


But I'm curious:

> which is a valid VCG file (you can launch your favorite VCG
> viewer on it unmodified)

What should be my "favorite VCG viewer"?

Google lead me to
, where
I downloaded 'vcg.20050204.tgz' (which I understand is the 1995 sources
with just some licensing changed?), which I managed to build, but which
fails to run on a simple file:

Waite*** stack smashing detected ***:  
terminated
Aborted (core dumped)

I found the patch from
 to cure
that one problem.

(It seems that vcg is not packaged in Debian/Ubuntu anymore, nowadays?)

> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi

> +@item -fcallgraph-info
> +@itemx -fcallgraph-info=@var{MARKERS}
> +@opindex fcallgraph-info
> +Makes the compiler output callgraph information for the program, on a
> +per-file basis.  The information is generated in the common VCG format.

Eh, "common VCG format" -- maybe common in the mid-90s?  ;-)

> +It can be decorated with additional, per-node and/or per-edge information,
> +if a list of comma-separated markers is additionally specified.  When the
> +@code{su} marker is specified, the callgraph is decorated with stack usage
> +information; it is equivalent to @option{-fstack-usage}.  When the @code{da}
> +marker is specified, the callgraph is decorated with information about
> +dynamically allocated objects.

I tried that, but 'xvcg' didn't render anything useful for a
'-fcallgraph-info=su,da' dump, hmm.


Also, I found that many years ago, in 2012, Steven Bosscher did "Rework
RTL CFG graph dumping to dump DOT format" (that's Graphviz), and then did
"remove vcg CFG dumper".

Note that I'm not actively objecting VCG if there's a good reason to use
unmaintained mid-90s software, containing obfuscated layout/rendering
source code (as far as I understand), not really in spirit of its GPL
license?  (But I'm not a lawyer, of course.)

So I guess I'm just curious why it's now coming back.


Grüße
 Thomas


signature.asc
Description: PGP signature

Re: introduce -fcallgraph-info option

[Alexandre Oliva]

On Nov  4, 2019, Richard Biener  wrote:

> I wonder why we shouldn't simply adjust aux_base_name to something
> else for -flto [in the driver].

About that, having tried to make sense of the current uses of
aux_base_name and of lto-wrapper, three main possibilities occur to me:

a) adjust the driver code to accept -auxbase, and have lto-wrapper
explicitly pass -aux-base ${output_dir-.}/$(lbasename ${output_name}) or
somesuch for each -fltrans command;

b) introduce -auxdir and get lto-wrapper to pass -auxdir ${output_dir-.}
for each -fltrans (and offload) command; or

c) get -fltrans to implicitly adjust aux_base_name with the directory
passed to -dumpdir, if any, or . otherwise

Any preferences?

-- 
Alexandre Oliva, freedom fighter   he/him   https://FSFLA.org/blogs/lxo
Free Software Evangelist   Stallman was right, but he's left :(
GNU Toolchain EngineerFSMatrix: It was he who freed the first of us
FSF & FSFLA board memberThe Savior shall return (true);

Re: introduce -fcallgraph-info option

[Alexandre Oliva]

On Nov  4, 2019, Richard Biener  wrote:

> Please leave that part out for now, I'd rather discuss this separately
> from the bulk of the patch.  That is, I wonder why we shouldn't
> simply adjust aux_base_name to something else for -flto [in the driver].

*nod*, that makes sense to me.  After seeing your suggestion, I started
looking into how to do that, but didn't get very far yet.  For now, I've
split that bit out of the main patch.  So I'm installing the first, big
one, and not installing the latter, posted mainly so that the
documentation bit can be picked up.  Thanks!


introduce -fcallgraph-info option

This was first submitted many years ago
https://gcc.gnu.org/ml/gcc-patches/2010-10/msg02468.html

The command line option -fcallgraph-info is added and makes the
compiler generate another output file (xxx.ci) for each compilation
unit (or LTO partitoin), which is a valid VCG file (you can launch
your favorite VCG viewer on it unmodified) and contains the "final"
callgraph of the unit.  "final" is a bit of a misnomer as this is
actually the callgraph at RTL expansion time, but since most
high-level optimizations are done at the Tree level and RTL doesn't
usually fiddle with calls, it's final in almost all cases.  Moreover,
the nodes can be decorated with additional info: -fcallgraph-info=su
adds stack usage info and -fcallgraph-info=da dynamic allocation info.


for  gcc/ChangeLog
>From  Eric Botcazou  , Alexandre Oliva  
>

* common.opt (-fcallgraph-info[=]): New option.
* doc/invoke.texi (Developer options): Document it.
* opts.c (common_handle_option): Handle it.
* builtins.c (expand_builtin_alloca): Record allocation if
-fcallgraph-info=da.
* calls.c (expand_call): If -fcallgraph-info, record the call.
(emit_library_call_value_1): Likewise.
* flag-types.h (enum callgraph_info_type): New type.
* explow.c: Include stringpool.h.
(set_stack_check_libfunc): Set SET_SYMBOL_REF_DECL on the symbol.
* function.c (allocate_stack_usage_info): New.
(allocate_struct_function): Call it for -fcallgraph-info.
(prepare_function_start): Call it otherwise.
(record_final_call, record_dynamic_alloc): New.
* function.h (struct callinfo_callee): New.
(CALLEE_FROM_CGRAPH_P): New.
(struct callinfo_dalloc): New.
(struct stack_usage): Add callees and dallocs.
(record_final_call, record_dynamic_alloc): Declare.
* gimplify.c (gimplify_decl_expr): Record dynamically-allocated
object if -fcallgraph-info=da.
* optabs-libfuncs.c (build_libfunc_function): Keep SYMBOL_REF_DECL.
* print-tree.h (print_decl_identifier): Declare.
(PRINT_DECL_ORIGIN, PRINT_DECL_NAME, PRINT_DECL_UNIQUE_NAME): New.
* print-tree.c: Include print-tree.h.
(print_decl_identifier): New function.
* toplev.c: Include print-tree.h.
(callgraph_info_file): New global variable.
(callgraph_info_external_printed): Likewise.
(output_stack_usage): Rename to...
(output_stack_usage_1): ... this.  Make it static, add cf
parameter.  If -fcallgraph-info=su, print stack usage to cf.
If -fstack-usage, use print_decl_identifier for
pretty-printing.
(INDIRECT_CALL_NAME): New.
(dump_final_node_vcg_start): New.
(dump_final_callee_vcg, dump_final_node_vcg): New.
(output_stack_usage): New.
(lang_dependent_init): Open and start file if
-fcallgraph-info.  Allocated callgraph_info_external_printed.
(finalize): If callgraph_info_file is not null, finish it,
close it, and release callgraph_info_external_printed.

for  gcc/ada/ChangeLog

* gcc-interface/misc.c (callgraph_info_file): Delete.
---
 gcc/ada/gcc-interface/misc.c |3 -
 gcc/builtins.c   |4 +
 gcc/calls.c  |6 +
 gcc/common.opt   |8 ++
 gcc/doc/invoke.texi  |   23 +
 gcc/explow.c |5 +
 gcc/flag-types.h |   16 
 gcc/function.c   |   59 +-
 gcc/function.h   |   30 +++
 gcc/gimplify.c   |4 +
 gcc/optabs-libfuncs.c|4 -
 gcc/opts.c   |   26 ++
 gcc/output.h |2 
 gcc/print-tree.c |   76 ++
 gcc/print-tree.h |4 +
 gcc/toplev.c |  178 ++
 16 files changed, 397 insertions(+), 51 deletions(-)

diff --git a/gcc/ada/gcc-interface/misc.c b/gcc/ada/gcc-interface/misc.c
index 4abd4d5..d68b373 100644
--- a/gcc/ada/gcc-interface/misc.c
+++ b/gcc/ada/gcc-interface/misc.c
@@ -54,9 +54,6 @@
 #include "ada-tree.h"
 #include "gigi.h"
 
-/* This symbol needs to be defined for the front-end.  */
-void *callgraph_info_file = NULL;
-
 /* Command-line argc and argv.  These variables are global since they are
im

Re: introduce -fcallgraph-info option

[Richard Biener]

On Sat, 2 Nov 2019, Alexandre Oliva wrote:

> On Oct 30, 2019, Richard Biener  wrote:
> 
> > One way of operation would be to
> > generate the graph during the compilation step
> 
> Stack usage is only computed during prologue/epilogue generation in RTL.
> 
> > Additional arguments to -fcallgraph-info might be used to direct the
> > output to a specific directory as well.
> 
> I've adjusted open_auxiliary_file for LTO recompilation auxiliary files
> to be placed in the same location as the specified executable output
> name, and noted that in the documentation.

Please leave that part out for now, I'd rather discuss this separately
from the bulk of the patch.  That is, I wonder why we shouldn't
simply adjust aux_base_name to something else for -flto [in the driver].

> I've also added a bitmap to output nodes for externals, accidentally
> dropped in the transition to incremental generation of the .ci file.
> 
> Regstrapped on x86_64-linux-gnu.  Ok to install?

OK for the rest.

Thanks,
Richard.

> 
> introduce -fcallgraph-info option
> 
> This was first submitted many years ago
> https://gcc.gnu.org/ml/gcc-patches/2010-10/msg02468.html
> 
> The command line option -fcallgraph-info is added and makes the
> compiler generate another output file (xxx.ci) for each compilation
> unit (or LTO partitoin), which is a valid VCG file (you can launch
> your favorite VCG viewer on it unmodified) and contains the "final"
> callgraph of the unit.  "final" is a bit of a misnomer as this is
> actually the callgraph at RTL expansion time, but since most
> high-level optimizations are done at the Tree level and RTL doesn't
> usually fiddle with calls, it's final in almost all cases.  Moreover,
> the nodes can be decorated with additional info: -fcallgraph-info=su
> adds stack usage info and -fcallgraph-info=da dynamic allocation info.
> 
> 
> for  gcc/ChangeLog
> From  Eric Botcazou  , Alexandre Oliva  
> 
> 
>   * common.opt (-fcallgraph-info[=]): New option.
>   * doc/invoke.texi (Developer options): Document it.
>   * opts.c (common_handle_option): Handle it.
>   * builtins.c (expand_builtin_alloca): Record allocation if
>   -fcallgraph-info=da.
>   * calls.c (expand_call): If -fcallgraph-info, record the call.
>   (emit_library_call_value_1): Likewise.
>   * flag-types.h (enum callgraph_info_type): New type.
>   * explow.c: Include stringpool.h.
>   (set_stack_check_libfunc): Set SET_SYMBOL_REF_DECL on the symbol.
>   * function.c (allocate_stack_usage_info): New.
>   (allocate_struct_function): Call it for -fcallgraph-info.
>   (prepare_function_start): Call it otherwise.
>   (record_final_call, record_dynamic_alloc): New.
>   * function.h (struct callinfo_callee): New.
>   (CALLEE_FROM_CGRAPH_P): New.
>   (struct callinfo_dalloc): New.
>   (struct stack_usage): Add callees and dallocs.
>   (record_final_call, record_dynamic_alloc): Declare.
>   * gimplify.c (gimplify_decl_expr): Record dynamically-allocated
>   object if -fcallgraph-info=da.
>   * optabs-libfuncs.c (build_libfunc_function): Keep SYMBOL_REF_DECL.
>   * print-tree.h (print_decl_identifier): Declare.
>   (PRINT_DECL_ORIGIN, PRINT_DECL_NAME, PRINT_DECL_UNIQUE_NAME): New.
>   * print-tree.c: Include print-tree.h.
>   (print_decl_identifier): New function.
>   * toplev.c: Include print-tree.h.
>   (callgraph_info_file): New global variable.
>   (callgraph_info_external_printed): Likewise.
>   (open_auxiliary_file): Use dump_base_name for LTO partitions.
>   (output_stack_usage): Rename to...
>   (output_stack_usage_1): ... this.  Make it static, add cf
>   parameter.  If -fcallgraph-info=su, print stack usage to cf.
>   If -fstack-usage, use print_decl_identifier for
>   pretty-printing.
>   (INDIRECT_CALL_NAME): New.
>   (dump_final_node_vcg_start): New.
>   (dump_final_callee_vcg, dump_final_node_vcg): New.
>   (output_stack_usage): New.
>   (lang_dependent_init): Open and start file if
>   -fcallgraph-info.  Allocated callgraph_info_external_printed.
>   (finalize): If callgraph_info_file is not null, finish it,
>   close it, and release callgraph_info_external_printed.
> 
> for  gcc/ada/ChangeLog
> 
>   * gcc-interface/misc.c (callgraph_info_file): Delete.
> ---
>  gcc/ada/gcc-interface/misc.c |3 -
>  gcc/builtins.c   |4 +
>  gcc/calls.c  |6 +
>  gcc/common.opt   |8 ++
>  gcc/doc/invoke.texi  |   22 +
>  gcc/explow.c |5 +
>  gcc/flag-types.h |   16 
>  gcc/function.c   |   59 -
>  gcc/function.h   |   30 +++
>  gcc/gimplify.c   |4 +
>  gcc/optabs-libfuncs.c|4 -
>  gcc/opts.c   |   26 ++
>  gcc/output.h |2 
>  gcc/print-tree.c |   76 +
>  gcc/pri

Re: introduce -fcallgraph-info option

[Alexandre Oliva]

On Oct 30, 2019, Richard Biener  wrote:

> One way of operation would be to
> generate the graph during the compilation step

Stack usage is only computed during prologue/epilogue generation in RTL.

> Additional arguments to -fcallgraph-info might be used to direct the
> output to a specific directory as well.

I've adjusted open_auxiliary_file for LTO recompilation auxiliary files
to be placed in the same location as the specified executable output
name, and noted that in the documentation.

I've also added a bitmap to output nodes for externals, accidentally
dropped in the transition to incremental generation of the .ci file.

Regstrapped on x86_64-linux-gnu.  Ok to install?


introduce -fcallgraph-info option

This was first submitted many years ago
https://gcc.gnu.org/ml/gcc-patches/2010-10/msg02468.html

The command line option -fcallgraph-info is added and makes the
compiler generate another output file (xxx.ci) for each compilation
unit (or LTO partitoin), which is a valid VCG file (you can launch
your favorite VCG viewer on it unmodified) and contains the "final"
callgraph of the unit.  "final" is a bit of a misnomer as this is
actually the callgraph at RTL expansion time, but since most
high-level optimizations are done at the Tree level and RTL doesn't
usually fiddle with calls, it's final in almost all cases.  Moreover,
the nodes can be decorated with additional info: -fcallgraph-info=su
adds stack usage info and -fcallgraph-info=da dynamic allocation info.


for  gcc/ChangeLog
>From  Eric Botcazou  , Alexandre Oliva  
>

* common.opt (-fcallgraph-info[=]): New option.
* doc/invoke.texi (Developer options): Document it.
* opts.c (common_handle_option): Handle it.
* builtins.c (expand_builtin_alloca): Record allocation if
-fcallgraph-info=da.
* calls.c (expand_call): If -fcallgraph-info, record the call.
(emit_library_call_value_1): Likewise.
* flag-types.h (enum callgraph_info_type): New type.
* explow.c: Include stringpool.h.
(set_stack_check_libfunc): Set SET_SYMBOL_REF_DECL on the symbol.
* function.c (allocate_stack_usage_info): New.
(allocate_struct_function): Call it for -fcallgraph-info.
(prepare_function_start): Call it otherwise.
(record_final_call, record_dynamic_alloc): New.
* function.h (struct callinfo_callee): New.
(CALLEE_FROM_CGRAPH_P): New.
(struct callinfo_dalloc): New.
(struct stack_usage): Add callees and dallocs.
(record_final_call, record_dynamic_alloc): Declare.
* gimplify.c (gimplify_decl_expr): Record dynamically-allocated
object if -fcallgraph-info=da.
* optabs-libfuncs.c (build_libfunc_function): Keep SYMBOL_REF_DECL.
* print-tree.h (print_decl_identifier): Declare.
(PRINT_DECL_ORIGIN, PRINT_DECL_NAME, PRINT_DECL_UNIQUE_NAME): New.
* print-tree.c: Include print-tree.h.
(print_decl_identifier): New function.
* toplev.c: Include print-tree.h.
(callgraph_info_file): New global variable.
(callgraph_info_external_printed): Likewise.
(open_auxiliary_file): Use dump_base_name for LTO partitions.
(output_stack_usage): Rename to...
(output_stack_usage_1): ... this.  Make it static, add cf
parameter.  If -fcallgraph-info=su, print stack usage to cf.
If -fstack-usage, use print_decl_identifier for
pretty-printing.
(INDIRECT_CALL_NAME): New.
(dump_final_node_vcg_start): New.
(dump_final_callee_vcg, dump_final_node_vcg): New.
(output_stack_usage): New.
(lang_dependent_init): Open and start file if
-fcallgraph-info.  Allocated callgraph_info_external_printed.
(finalize): If callgraph_info_file is not null, finish it,
close it, and release callgraph_info_external_printed.

for  gcc/ada/ChangeLog

* gcc-interface/misc.c (callgraph_info_file): Delete.
---
 gcc/ada/gcc-interface/misc.c |3 -
 gcc/builtins.c   |4 +
 gcc/calls.c  |6 +
 gcc/common.opt   |8 ++
 gcc/doc/invoke.texi  |   22 +
 gcc/explow.c |5 +
 gcc/flag-types.h |   16 
 gcc/function.c   |   59 -
 gcc/function.h   |   30 +++
 gcc/gimplify.c   |4 +
 gcc/optabs-libfuncs.c|4 -
 gcc/opts.c   |   26 ++
 gcc/output.h |2 
 gcc/print-tree.c |   76 +
 gcc/print-tree.h |4 +
 gcc/toplev.c |  186 ++
 16 files changed, 402 insertions(+), 53 deletions(-)

diff --git a/gcc/ada/gcc-interface/misc.c b/gcc/ada/gcc-interface/misc.c
index 4abd4d5..d68b373 100644
--- a/gcc/ada/gcc-interface/misc.c
+++ b/gcc/ada/gcc-interface/misc.c
@@ -54,9 +54,6 @@
 #include "ada-tree.h"
 #include "gigi.h"
 
-/

Re: introduce -fcallgraph-info option

[Joseph Myers]

On Wed, 30 Oct 2019, Alexandre Oliva wrote:

> On Oct 28, 2019, Joseph Myers  wrote:
> 
> > We have a test in the testsuite that all option help text consistently 
> > ends with '.' (see gcc.misc-tests/help.exp).  I'd have expected these 
> > options, lacking that '.', to cause that test to fail.
> 
> Here's the patch.  Tested on x86_64-linux-gnu.  Ok to install?
> 
> 
> Test --help=common for full sentences
> 
> The portion of help.exp that checks that help output contains full
> sentences failed to cover common options.

OK.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: introduce -fcallgraph-info option

[Richard Biener]

On Wed, 30 Oct 2019, Alexandre Oliva wrote:

> On Oct 28, 2019, Richard Biener  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.

Re: introduce -fcallgraph-info option

[Alexandre Oliva]

On Oct 28, 2019, Richard Biener  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

-- 
Alexandre Oliva, freedom fighter  he/him   https://FSFLA.org/blogs/lxo
Be the change, be Free!FSF VP & FSF Latin America board member
GNU Toolchain EngineerFree Software Evangelist
Hay que enGNUrecerse, pero sin perder la terGNUra jamás - Che GNUevara

Re: introduce -fcallgraph-info option

[Alexandre Oliva]

On Oct 28, 2019, Joseph Myers  wrote:

> We have a test in the testsuite that all option help text consistently 
> ends with '.' (see gcc.misc-tests/help.exp).  I'd have expected these 
> options, lacking that '.', to cause that test to fail.

Here's the patch.  Tested on x86_64-linux-gnu.  Ok to install?


Test --help=common for full sentences

The portion of help.exp that checks that help output contains full
sentences failed to cover common options.


for  gcc/testsuite/ChangeLog

* gcc.misc-tests/help.exp: Test --help=common for full sentences.
---
 gcc/testsuite/gcc.misc-tests/help.exp |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/gcc/testsuite/gcc.misc-tests/help.exp 
b/gcc/testsuite/gcc.misc-tests/help.exp
index b8a09fc..4bb359f 100644
--- a/gcc/testsuite/gcc.misc-tests/help.exp
+++ b/gcc/testsuite/gcc.misc-tests/help.exp
@@ -146,8 +146,7 @@ check_for_options c "--help=joined,undocumented" "" "" ""
 # find the source a failure.
 
 foreach cls { "ada" "c" "c++" "d" "fortran" "go" \
-   "optimizers" "param" "target" "warnings" } {
-
+   "common" "optimizers" "param" "target" "warnings" } {
 check_for_options c "--help=$cls" "" "^ +-.*\[^:.\]$" ""
 }
 


-- 
Alexandre Oliva, freedom fighter  he/him   https://FSFLA.org/blogs/lxo
Be the change, be Free!FSF VP & FSF Latin America board member
GNU Toolchain EngineerFree Software Evangelist
Hay que enGNUrecerse, pero sin perder la terGNUra jamás - Che GNUevara

Re: introduce -fcallgraph-info option

[Alexandre Oliva]

On Oct 28, 2019, Joseph Myers  wrote:

> We have a test in the testsuite that all option help text consistently 
> ends with '.' (see gcc.misc-tests/help.exp).  I'd have expected these 
> options, lacking that '.', to cause that test to fail.

Thanks.  I've fixed the common.opt changes, and I'll submit momentarily
a patch for help.exp to extend it to cover --help=common output as well.

-- 
Alexandre Oliva, freedom fighter  he/him   https://FSFLA.org/blogs/lxo
Be the change, be Free!FSF VP & FSF Latin America board member
GNU Toolchain EngineerFree Software Evangelist
Hay que enGNUrecerse, pero sin perder la terGNUra jamás - Che GNUevara

Re: introduce -fcallgraph-info option

[Joseph Myers]

On Sat, 26 Oct 2019, Alexandre Oliva wrote:

> Regstrapped on x86_64-linux-gnu.  Ok to install?

I have only a peripheral comment:

> diff --git a/gcc/common.opt b/gcc/common.opt
> index cc279f411d796..63d646fba2b42 100644
> --- a/gcc/common.opt
> +++ b/gcc/common.opt
> @@ -1091,6 +1091,14 @@ fbtr-bb-exclusive
>  Common Ignore
>  Does nothing.  Preserved for backward compatibility.
>  
> +fcallgraph-info
> +Common Report RejectNegative Var(flag_callgraph_info) 
> Init(NO_CALLGRAPH_INFO);
> +Output callgraph information on a per-file basis
> +
> +fcallgraph-info=
> +Common Report RejectNegative Joined
> +Output callgraph information on a per-file basis with decorations

We have a test in the testsuite that all option help text consistently 
ends with '.' (see gcc.misc-tests/help.exp).  I'd have expected these 
options, lacking that '.', to cause that test to fail.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: introduce -fcallgraph-info option

[Richard Biener]

On Sun, 27 Oct 2019, Alexandre Oliva wrote:

> On Oct 26, 2019, Alexandre Oliva  wrote:
> 
> > E.g., the reason we gather expanded calls rather than just use
> > cgraph_edges is that the latter would dump several "calls" that are
> > builtins expanded internally by the compiler, and would NOT dump other
> > ops that are expanded as (lib)calls.
> 
> It occurred to me that we could reuse most cgraph edges and avoid
> duplicating them in the callees vec, namely those that aren't builtins
> or libcalls.  Those that are builtins might or might not become actual
> calls, so we disregard the cgraph_edges and record them in the vec
> instead.  Those that are libcalls (builtins in a different sense)
> introduced during expand are not even present in the cgraph edges, so we
> record them in the vec as well.  Here's the patch that implements this.
> 
> Regstrapped on x86_64-linux-gnu.  Ok to install?

<...>

> --- a/gcc/common.opt
> +++ b/gcc/common.opt
> @@ -1091,6 +1091,14 @@ fbtr-bb-exclusive
>  Common Ignore
>  Does nothing.  Preserved for backward compatibility.
>  
> +fcallgraph-info
> +Common Report RejectNegative Var(flag_callgraph_info) 
> Init(NO_CALLGRAPH_INFO);
> +Output callgraph information on a per-file basis
> +
> +fcallgraph-info=
> +Common Report RejectNegative Joined
> +Output callgraph information on a per-file basis with decorations
> +
>  fcall-saved-
>  Common Joined RejectNegative Var(common_deferred_options) Defer
>  -fcall-saved-  Mark  as being preserved across 
> functions.
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index 1407d019d1404..545b842eade71 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -583,8 +583,9 @@ Objective-C and Objective-C++ Dialects}.
>  @item Developer Options
>  @xref{Developer Options,,GCC Developer Options}.
>  @gccoptlist{-d@var{letters}  -dumpspecs  -dumpmachine  -dumpversion @gol
> --dumpfullversion  -fchecking  -fchecking=@var{n}  -fdbg-cnt-list @gol
> --fdbg-cnt=@var{counter-value-list} @gol
> +-dumpfullversion  -fcallgraph-info@r{[}=su,da@r{]}
> +-fchecking  -fchecking=@var{n}
> +-fdbg-cnt-list @gol  -fdbg-cnt=@var{counter-value-list} @gol
>  -fdisable-ipa-@var{pass_name} @gol
>  -fdisable-rtl-@var{pass_name} @gol
>  -fdisable-rtl-@var{pass-name}=@var{range-list} @gol
> @@ -14533,6 +14534,18 @@ The files are created in the directory of the output 
> file.
>  
>  @table @gcctabopt
>  
> +@item -fcallgraph-info
> +@itemx -fcallgraph-info=@var{MARKERS}
> +@opindex fcallgraph-info
> +Makes the compiler output callgraph information for the program, on a
> +per-file basis.  The information is generated in the common VCG format.

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?).

Is this mainly a debugging tool or does it serve a different purpose?

Otherwise OK.

Thanks,
Richard.

> +It can be decorated with additional, per-node and/or per-edge information,
> +if a list of comma-separated markers is additionally specified.  When the
> +@code{su} marker is specified, the callgraph is decorated with stack usage
> +information; it is equivalent to @option{-fstack-usage}.  When the @code{da}
> +marker is specified, the callgraph is decorated with information about
> +dynamically allocated objects.

Re: introduce -fcallgraph-info option

[Alexandre Oliva]

On Oct 26, 2019, Alexandre Oliva  wrote:

> E.g., the reason we gather expanded calls rather than just use
> cgraph_edges is that the latter would dump several "calls" that are
> builtins expanded internally by the compiler, and would NOT dump other
> ops that are expanded as (lib)calls.

It occurred to me that we could reuse most cgraph edges and avoid
duplicating them in the callees vec, namely those that aren't builtins
or libcalls.  Those that are builtins might or might not become actual
calls, so we disregard the cgraph_edges and record them in the vec
instead.  Those that are libcalls (builtins in a different sense)
introduced during expand are not even present in the cgraph edges, so we
record them in the vec as well.  Here's the patch that implements this.

Regstrapped on x86_64-linux-gnu.  Ok to install?

for  gcc/ChangeLog
>From  Eric Botcazou  , Alexandre Oliva  
>

* common.opt (-fcallgraph-info[=]): New option.
* doc/invoke.texi (Debugging options): Document it.
* opts.c (common_handle_option): Handle it.
* builtins.c (expand_builtin_alloca): Record allocation if
-fcallgraph-info=da.
* calls.c (expand_call): If -fcallgraph-info, record the call.
(emit_library_call_value_1): Likewise.
* flag-types.h (enum callgraph_info_type): New type.
* explow.c: Include stringpool.h.
(set_stack_check_libfunc): Set SET_SYMBOL_REF_DECL on the symbol.
* function.c (allocate_stack_usage_info): New.
(allocate_struct_function): Call it for -fcallgraph-info.
(prepare_function_start): Call it otherwise.
(record_final_call, record_dynamic_alloc): New.
* function.h (struct callinfo_callee): New.
(CALLEE_FROM_CGRAPH_P): New.
(struct callinfo_dalloc): New.
(struct stack_usage): Add callees and dallocs.
(record_final_call, record_dynamic_alloc): Declare.
* gimplify.c (gimplify_decl_expr): Record dynamically-allocated
object if -fcallgraph-info=da.
* optabs-libfuncs.c (build_libfunc_function): Keep SYMBOL_REF_DECL.
* print-tree.h (print_decl_identifier): Declare.
(PRINT_DECL_ORIGIN, PRINT_DECL_NAME, PRINT_DECL_UNIQUE_NAME): New.
* print-tree.c: Include print-tree.h.
(print_decl_identifier): New function.
* toplev.c: Include print-tree.h.
(callgraph_info_file): New global variable.
(callgraph_info_indirect_emitted): Likewise.
(output_stack_usage): Rename to...
(output_stack_usage_1): ... this.  Make it static, add cf
parameter.  If -fcallgraph-info=su, print stack usage to cf.
If -fstack-usage, use print_decl_identifier for
pretty-printing.
(INDIRECT_CALL_NAME): New.
(dump_final_indirect_call_node_vcg): New.
(dump_final_callee_vcg, dump_final_node_vcg): New.
(output_stack_usage): New.
(lang_dependent_init): Open and start file if
-fcallgraph-info.
(finalize): If callgraph_info_file is not null, finish it,
close it, and reset callgraph info state.

for  gcc/ada/ChangeLog

* gcc-interface/misc.c (callgraph_info_file): Delete.
---
 gcc/ada/gcc-interface/misc.c |3 -
 gcc/builtins.c   |4 +
 gcc/calls.c  |6 +
 gcc/common.opt   |8 ++
 gcc/doc/invoke.texi  |   17 
 gcc/explow.c |5 +
 gcc/flag-types.h |   16 
 gcc/function.c   |   59 --
 gcc/function.h   |   30 +++
 gcc/gimplify.c   |4 +
 gcc/optabs-libfuncs.c|4 -
 gcc/opts.c   |   26 ++
 gcc/output.h |2 
 gcc/print-tree.c |   76 ++
 gcc/print-tree.h |4 +
 gcc/toplev.c |  179 ++
 16 files changed, 393 insertions(+), 50 deletions(-)

diff --git a/gcc/ada/gcc-interface/misc.c b/gcc/ada/gcc-interface/misc.c
index 4abd4d5708a54..d68b37384ff7f 100644
--- a/gcc/ada/gcc-interface/misc.c
+++ b/gcc/ada/gcc-interface/misc.c
@@ -54,9 +54,6 @@
 #include "ada-tree.h"
 #include "gigi.h"
 
-/* This symbol needs to be defined for the front-end.  */
-void *callgraph_info_file = NULL;
-
 /* Command-line argc and argv.  These variables are global since they are
imported in back_end.adb.  */
 unsigned int save_argc;
diff --git a/gcc/builtins.c b/gcc/builtins.c
index 5d811f113c907..bd302383377ba 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -5406,6 +5406,10 @@ expand_builtin_alloca (tree exp)
 = allocate_dynamic_stack_space (op0, 0, align, max_size, alloca_for_var);
   result = convert_memory_address (ptr_mode, result);
 
+  /* Dynamic allocations for variables are recorded during gimplification.  */
+  if (!alloca_for_var && (flag_callgraph_info & CALLGRAPH_INFO_DYNAMIC_ALLOC))
+record_dynamic_alloc (exp);
+
   return result;
 }
 
diff --g

Re: introduce -fcallgraph-info option

[Alexandre Oliva]

Hi, Richi,

On Oct 26, 2019, Richard Biener  wrote:

> How does it relate to the LTO-dump utility we have now which can in
> theory provide a more complete view?

Erhm...  Not at all, AFAICT.  The only vague resemblance I see is in the
presence of the word "callgraph" in the description of what both can do,
but even that's not quite the same callgraph, besides the different
format.

E.g., the reason we gather expanded calls rather than just use
cgraph_edges is that the latter would dump several "calls" that are
builtins expanded internally by the compiler, and would NOT dump other
ops that are expanded as (lib)calls.  In order to get an accurate
assessment of stack size requirements, the presence of the builtins
could be confusing but not so much trouble, but the absence of libcalls
would underestimate the potential max total stack use by a symbol.

> Maybe some infrastructure can be
> shared here (the actual dumping of the cgraph?)

You mean the one-liner loop in cgraph_node::dump_graphviz, called by
lto-dump to dump the cgraph?  That doesn't really seem worth sharing;
more so considering we dump edges in a quite different format, and not
just the edges.  In this different format expected by gnatstack, we also
dump the nodes, and include information in the labels of the nodes, such
as their original spelling and location, as well as stack use:

node: { title: "_ada_p" label: "P\np.adb:1:1\n48 bytes (static)" }

and dynamic stack allocations (alloca and vlas):

node: { title: "p.adb:p__u" label: "u\np.adb:21:3\n2 dynamic objects\n rt 
p.adb:23:5\n ri p.adb:24:5" }

and though edges to libcalls may carry just as little info as a graphviz
"from" -> "to" edge:

edge: { sourcename: "add" targetname: "__addvsi3" }

those between user symbols carry location info as well:

edge: { sourcename: "p__s" targetname: "p.adb:p__v" label: "p.adb:46:5" }

So I'm afraid I don't see anything that could be usefully factored out.
Do you?

Thanks,

-- 
Alexandre Oliva, freedom fighter  he/him   https://FSFLA.org/blogs/lxo
Be the change, be Free!FSF VP & FSF Latin America board member
GNU Toolchain EngineerFree Software Evangelist
Hay que enGNUrecerse, pero sin perder la terGNUra jamás - Che GNUevara

Re: introduce -fcallgraph-info option

[Richard Biener]

On October 26, 2019 6:35:43 AM GMT+02:00, Alexandre Oliva  
wrote:
>This was first submitted many years ago
>https://gcc.gnu.org/ml/gcc-patches/2010-10/msg02468.html
>
>The command line option -fcallgraph-info is added and makes the
>compiler generate another output file (xxx.ci) for each compilation
>unit, which is a valid VCG file (you can launch your favorite VCG
>viewer on it unmodified) and contains the "final" callgraph of the
>unit.  "final" is a bit of a misnomer as this is actually the
>callgraph at RTL expansion time, but since most high-level
>optimizations are done at the Tree level and RTL doesn't usually
>fiddle with calls, it's final in almost all cases.  Moreover, the
>nodes can be decorated with additional info: -fcallgraph-info=su adds
>stack usage info and -fcallgraph-info=da dynamic allocation info.
>
>Compared with the earlier version, this patch does not modify cgraph,
>and instead adds the required information next to the stage usage
>function data structure, so we only hold one of those at at time.  I've
>switched to vecs from linked lists, for more compact edges and dynamic
>allocation annotations, and arranged for them to be released as soon as
>we've printed out the information.  I have NOT changed the file format,
>because existing tools such as gnatstack consume the current format.
>
>Regstrapped on x86_64-linux-gnu.  Ok to install?

How does it relate to the LTO-dump utility we have now which can in theory 
provide a more complete view? Maybe some infrastructure can be shared here (the 
actual dumping of the cgraph?) 

Thanks, 
Richard. 

>
>for  gcc/ChangeLog
>From  Eric Botcazou  , Alexandre Oliva 
>
>
>   * common.opt (-fcallgraph-info[=]): New option.
>   * doc/invoke.texi (Debugging options): Document it.
>   * opts.c (common_handle_option): Handle it.
>   * builtins.c (expand_builtin_alloca): Record allocation if
>   -fcallgraph-info=da.
>   * calls.c (expand_call): If -fcallgraph-info, record the call.
>   (emit_library_call_value_1): Likewise.
>   * flag-types.h (enum callgraph_info_type): New type.
>   * explow.c: Include stringpool.h.
>   (set_stack_check_libfunc): Set SET_SYMBOL_REF_DECL on the symbol.
>   * function.c (allocate_stack_usage_info): New.
>   (allocate_struct_function): Call it for -fcallgraph-info.
>   (prepare_function_start): Call it otherwise.
>   (rest_of_handle_thread_prologue_and_epilogue): Release callees
>   and dallocs after output_stack_usage.
>   (record_final_call, record_dynamic_alloc): New.
>   * function.h (struct callee, struct dalloc): New.
>   (struct stack_usage): Add callees and dallocs.
>   (record_final_call, record_dynamic_alloc): Declare.
>   * gimplify.c (gimplify_decl_expr): Record dynamically-allocated
>   object if -fcallgraph-info=da.
>   * optabs-libfuncs.c (build_libfunc_function): Keep SYMBOL_REF_DECL.
>   * print-tree.h (print_decl_identifier): Declare.
>   (PRINT_DECL_ORIGIN, PRINT_DECL_NAME, PRINT_DECL_UNIQUE_NAME): New.
>   * print-tree.c: Include print-tree.h.
>   (print_decl_identifier): New function.
>   * toplev.c: Include print-tree.h.
>   (callgraph_info_file): New global variable.
>   (callgraph_info_indirect_emitted): Likewise.
>   (output_stack_usage): Rename to...
>   (output_stack_usage_1): ... this.  Make it static, add cf
>   parameter.  If -fcallgraph-info=su, print stack usage to cf.
>   If -fstack-usage, use print_decl_identifier for
>   pretty-printing.
>   (INDIRECT_CALL_NAME): New.
>   (dump_final_indirect_call_node_vcg): New.
>   (dump_final_callee_vcg, dump_final_node_vcg): New.
>   (output_stack_usage): New.
>   (lang_dependent_init): Open and start file if
>   -fcallgraph-info.
>   (finalize): If callgraph_info_file is not null, finish it,
>   close it, and reset callgraph info state.
>
>for  gcc/ada/ChangeLog
>
>   * gcc-interface/misc.c (callgraph_info_file): Delete.
>---
> gcc/ada/gcc-interface/misc.c |3 -
> gcc/builtins.c   |4 +
> gcc/calls.c  |6 +
> gcc/common.opt   |8 ++
> gcc/doc/invoke.texi  |   17 
> gcc/explow.c |5 +
> gcc/flag-types.h |   16 
> gcc/function.c   |   63 ++--
> gcc/function.h   |   25 ++
> gcc/gimplify.c   |4 +
> gcc/optabs-libfuncs.c|4 -
> gcc/opts.c   |   26 ++
> gcc/output.h |2 
> gcc/print-tree.c |   76 +++
> gcc/print-tree.h |4 +
>gcc/toplev.c |  169
>++
> 16 files changed, 381 insertions(+), 51 deletions(-)
>
>diff --git a/gcc/ada/gcc-interface/misc.c
>b/gcc/ada/gcc-interface/misc.c
>index 4abd4d5708a54..d68b37384ff7f 100644
>--- a/gcc/ada/gcc-interface/misc.c
>+++ b/gcc/ada/gcc-interface