Re: [GSOC] LTO dump tool project - feedback

[Hrishikesh Kulkarni]

Hi,

I have made changes for feedback points 3 and 10.

With this I have completed/ made changes for points
1,  3,  4,  5,  6,  7,  8,  9,  10,  11,  12.

I have pushed the changes to the repo. Please find the diff file
attached herewith.

Regards,

Hrishikesh
On Thu, Aug 16, 2018 at 7:50 PM Hrishikesh Kulkarni
 wrote:
>
> Hi,
>
> Thanks for the feedback.
> I have made the corrections for the feedback points:
> 1,  4,  5,  6,  7,  8,  9,  11,  12.
> I am working on the remaining points.
>
> I have pushed the changes to the repo (lto-dump-tool-v4 branch) and
> attached the diff file herewith.
>
> Regards,
>
> Hrishikesh
>
> On Wed, Aug 15, 2018 at 5:30 PM, Martin Liška  wrote:
> > Hi.
> >
> > After last update of the branch, there's a feedback that will be needed
> > before we can adept to have it merged into trunk:
> >
> > 1) there's patch for lto-dump proper install:
> >
> > diff --git a/gcc/lto/Make-lang.in b/gcc/lto/Make-lang.in
> > index e474f85ebc6..e9d2659025c 100644
> > --- a/gcc/lto/Make-lang.in
> > +++ b/gcc/lto/Make-lang.in
> > @@ -46,7 +46,10 @@ lto.all.cross: $(LTO_EXE) $(LTO_DUMP_EXE)
> >  lto.start.encap: $(LTO_EXE) $(LTO_DUMP_EXE)
> >  lto.rest.encap:
> >  lto.tags:
> > -lto.install-common:
> > +lto.install-common: installdirs
> > +   $(INSTALL_PROGRAM) $(LTO_DUMP_EXE) \
> > + $(DESTDIR)/$(bindir)/$(LTO_DUMP_EXE)
> > +
> >  lto.install-man:
> >  lto.install-info:
> >  lto.dvi:
> >
> > 2) If I build bzip2 (just add -flto into Makefile) with your branch I see 
> > an ICE:
> >
> > $ cd bzip2-1.0.6
> > $ make
> > [...]
> > gcc -Wall -Winline -O2 -g -D_FILE_OFFSET_BITS=64 -flto=9   -o bzip2 bzip2.o 
> > -L. -lbz2
> > lto1: internal compiler error: unexpected offset
> > 0x767bfc lto_resolution_read
> > ../../gcc/lto/lto-common.c:1951
> > 0x767bfc lto_file_read
> > ../../gcc/lto/lto-common.c:2169
> > 0x767bfc read_cgraph_and_symbols(unsigned int, char const**)
> > ../../gcc/lto/lto-common.c:2631
> > 0x74f042 lto_main()
> > ../../gcc/lto/lto.c:580
> >
> > 3) I still see an extra info that is not needed:
> >
> > Time variable   usr   sys  
> > wall   GGC
> >  phase setup:   0.00 (  0%)   0.00 (  0%)   0.00 (  
> > 0%)2029 kB ( 52%)
> >  phase parsing  :   0.01 (100%)   0.00 (  0%)   0.02 
> > (100%)1887 kB ( 48%)
> >  ipa cp :   0.00 (  0%)   0.00 (  0%)   0.01 ( 
> > 50%) 119 kB (  3%)
> >  ipa lto gimple in  :   0.00 (  0%)   0.00 (  0%)   0.00 (  
> > 0%)1136 kB ( 29%)
> >  tree operand scan  :   0.01 (100%)   0.00 (  0%)   0.01 ( 
> > 50%) 158 kB (  4%)
> >  TOTAL  :   0.01  0.00  0.02
> >3917 kB
> > Extra diagnostic checks enabled; compiler may run slowly.
> > Configure with --enable-checking=release to disable checks.
> >
> > 4) -list:
> >  a) please add header, it was useful
> >  b) -no-sort makes no sense to me, it's default isn't it?
> >
> > 5) -symbol=
> >  a) if symbol is not found, we should print an error
> > 6) -objects= - why '=' ?
> > 7) -type-stats - you have extra empty lines at the beginning
> >- please align header with values
> > 8) -tree-stats - probably also --enable-gather-.. is needed?
> > 9) -dump-body - again, if does not exist, error should be printed
> > 10) -dump-level - again error if wrong value, document possible values if 
> > possible
> > 11) please fix formatting of lto-dump so that it explains which suboptions 
> > are possible:
> >
> > $ gcov-tool --help
> > Usage: gcov-tool [OPTION]... SUB_COMMAND [OPTION]...
> >
> > Offline tool to handle gcda counts
> >
> >   -h, --helpPrint this help, then exit
> >   -v, --version Print version number, then exit
> >   merge [options]   Merge coverage file contents
> > -o, --output   Output directory
> > -v, --verbose   Verbose mode
> > -w, --weight Set weights (float point values)
> >   rewrite [options]Rewrite coverage file contents
> > -n, --normalizeNormalize the profile
> > -o, --output   Output directory
> > -s, --scale   Scale the profile counters
> > -v, --verbose   Verbose mode
> >   overlap [options] Compute the overlap of two profiles
> > -f, --function  Print function level info
> > -F, --fullname  Print full filename
> > -h, --hotonly   Only print info for hot 
> > objects/functions
> > -o, --objectPrint object level info
> > -t , --hot_threshold  Set the threshold for hotness
> > -v, --verbose   Verbose mode
> >
> > 12) Do not name it in documentation 'lto-dump-tool', use simply 'lto-dump'.
> > 

Re: [GSOC] LTO dump tool project - feedback

[Hrishikesh Kulkarni]

Hi,

Thanks for the feedback.
I have made the corrections for the feedback points:
1,  4,  5,  6,  7,  8,  9,  11,  12.
I am working on the remaining points.

I have pushed the changes to the repo (lto-dump-tool-v4 branch) and
attached the diff file herewith.

Regards,

Hrishikesh

On Wed, Aug 15, 2018 at 5:30 PM, Martin Liška  wrote:
> Hi.
>
> After last update of the branch, there's a feedback that will be needed
> before we can adept to have it merged into trunk:
>
> 1) there's patch for lto-dump proper install:
>
> diff --git a/gcc/lto/Make-lang.in b/gcc/lto/Make-lang.in
> index e474f85ebc6..e9d2659025c 100644
> --- a/gcc/lto/Make-lang.in
> +++ b/gcc/lto/Make-lang.in
> @@ -46,7 +46,10 @@ lto.all.cross: $(LTO_EXE) $(LTO_DUMP_EXE)
>  lto.start.encap: $(LTO_EXE) $(LTO_DUMP_EXE)
>  lto.rest.encap:
>  lto.tags:
> -lto.install-common:
> +lto.install-common: installdirs
> +   $(INSTALL_PROGRAM) $(LTO_DUMP_EXE) \
> + $(DESTDIR)/$(bindir)/$(LTO_DUMP_EXE)
> +
>  lto.install-man:
>  lto.install-info:
>  lto.dvi:
>
> 2) If I build bzip2 (just add -flto into Makefile) with your branch I see an 
> ICE:
>
> $ cd bzip2-1.0.6
> $ make
> [...]
> gcc -Wall -Winline -O2 -g -D_FILE_OFFSET_BITS=64 -flto=9   -o bzip2 bzip2.o 
> -L. -lbz2
> lto1: internal compiler error: unexpected offset
> 0x767bfc lto_resolution_read
> ../../gcc/lto/lto-common.c:1951
> 0x767bfc lto_file_read
> ../../gcc/lto/lto-common.c:2169
> 0x767bfc read_cgraph_and_symbols(unsigned int, char const**)
> ../../gcc/lto/lto-common.c:2631
> 0x74f042 lto_main()
> ../../gcc/lto/lto.c:580
>
> 3) I still see an extra info that is not needed:
>
> Time variable   usr   sys  
> wall   GGC
>  phase setup:   0.00 (  0%)   0.00 (  0%)   0.00 (  
> 0%)2029 kB ( 52%)
>  phase parsing  :   0.01 (100%)   0.00 (  0%)   0.02 
> (100%)1887 kB ( 48%)
>  ipa cp :   0.00 (  0%)   0.00 (  0%)   0.01 ( 
> 50%) 119 kB (  3%)
>  ipa lto gimple in  :   0.00 (  0%)   0.00 (  0%)   0.00 (  
> 0%)1136 kB ( 29%)
>  tree operand scan  :   0.01 (100%)   0.00 (  0%)   0.01 ( 
> 50%) 158 kB (  4%)
>  TOTAL  :   0.01  0.00  0.02  
>  3917 kB
> Extra diagnostic checks enabled; compiler may run slowly.
> Configure with --enable-checking=release to disable checks.
>
> 4) -list:
>  a) please add header, it was useful
>  b) -no-sort makes no sense to me, it's default isn't it?
>
> 5) -symbol=
>  a) if symbol is not found, we should print an error
> 6) -objects= - why '=' ?
> 7) -type-stats - you have extra empty lines at the beginning
>- please align header with values
> 8) -tree-stats - probably also --enable-gather-.. is needed?
> 9) -dump-body - again, if does not exist, error should be printed
> 10) -dump-level - again error if wrong value, document possible values if 
> possible
> 11) please fix formatting of lto-dump so that it explains which suboptions 
> are possible:
>
> $ gcov-tool --help
> Usage: gcov-tool [OPTION]... SUB_COMMAND [OPTION]...
>
> Offline tool to handle gcda counts
>
>   -h, --helpPrint this help, then exit
>   -v, --version Print version number, then exit
>   merge [options]   Merge coverage file contents
> -o, --output   Output directory
> -v, --verbose   Verbose mode
> -w, --weight Set weights (float point values)
>   rewrite [options]Rewrite coverage file contents
> -n, --normalizeNormalize the profile
> -o, --output   Output directory
> -s, --scale   Scale the profile counters
> -v, --verbose   Verbose mode
>   overlap [options] Compute the overlap of two profiles
> -f, --function  Print function level info
> -F, --fullname  Print full filename
> -h, --hotonly   Only print info for hot 
> objects/functions
> -o, --objectPrint object level info
> -t , --hot_threshold  Set the threshold for hotness
> -v, --verbose   Verbose mode
>
> 12) Do not name it in documentation 'lto-dump-tool', use simply 'lto-dump'.
> 13) make sure man page is generated for lto-dump
> 14) I noticed that you smashed some whitespaces for files where you didn't do 
> any
> changes: gcc/tree.c, lto.c(do_whole_program_analysis) and other places
> 15) test the tool on a bigger program built with LTO, ideally for both LGEN 
> and also
> LTRANS files
> 16) The last bigger challenge is the option handling, we currently 
> participate in lto/lang.opt.
> Ideally I would prefer using standard mechanism getopt_long, take a look at 
> gcov-dump.c.
> Can you please investigate that.
>
> Anyway, 

Re: [GSOC] LTO dump tool project - feedback

[Martin Liška]

Hi.

After last update of the branch, there's a feedback that will be needed
before we can adept to have it merged into trunk:

1) there's patch for lto-dump proper install:

diff --git a/gcc/lto/Make-lang.in b/gcc/lto/Make-lang.in
index e474f85ebc6..e9d2659025c 100644
--- a/gcc/lto/Make-lang.in
+++ b/gcc/lto/Make-lang.in
@@ -46,7 +46,10 @@ lto.all.cross: $(LTO_EXE) $(LTO_DUMP_EXE)
 lto.start.encap: $(LTO_EXE) $(LTO_DUMP_EXE)
 lto.rest.encap:
 lto.tags:
-lto.install-common:
+lto.install-common: installdirs
+   $(INSTALL_PROGRAM) $(LTO_DUMP_EXE) \
+ $(DESTDIR)/$(bindir)/$(LTO_DUMP_EXE)
+
 lto.install-man:
 lto.install-info:
 lto.dvi:

2) If I build bzip2 (just add -flto into Makefile) with your branch I see an 
ICE:

$ cd bzip2-1.0.6
$ make
[...]
gcc -Wall -Winline -O2 -g -D_FILE_OFFSET_BITS=64 -flto=9   -o bzip2 bzip2.o -L. 
-lbz2
lto1: internal compiler error: unexpected offset
0x767bfc lto_resolution_read
../../gcc/lto/lto-common.c:1951
0x767bfc lto_file_read
../../gcc/lto/lto-common.c:2169
0x767bfc read_cgraph_and_symbols(unsigned int, char const**)
../../gcc/lto/lto-common.c:2631
0x74f042 lto_main()
../../gcc/lto/lto.c:580

3) I still see an extra info that is not needed:

Time variable   usr   sys  wall 
  GGC
 phase setup:   0.00 (  0%)   0.00 (  0%)   0.00 (  0%) 
   2029 kB ( 52%)
 phase parsing  :   0.01 (100%)   0.00 (  0%)   0.02 (100%) 
   1887 kB ( 48%)
 ipa cp :   0.00 (  0%)   0.00 (  0%)   0.01 ( 50%) 
119 kB (  3%)
 ipa lto gimple in  :   0.00 (  0%)   0.00 (  0%)   0.00 (  0%) 
   1136 kB ( 29%)
 tree operand scan  :   0.01 (100%)   0.00 (  0%)   0.01 ( 50%) 
158 kB (  4%)
 TOTAL  :   0.01  0.00  0.02
   3917 kB
Extra diagnostic checks enabled; compiler may run slowly.
Configure with --enable-checking=release to disable checks.

4) -list:
 a) please add header, it was useful
 b) -no-sort makes no sense to me, it's default isn't it?

5) -symbol=
 a) if symbol is not found, we should print an error
6) -objects= - why '=' ?
7) -type-stats - you have extra empty lines at the beginning
   - please align header with values
8) -tree-stats - probably also --enable-gather-.. is needed?
9) -dump-body - again, if does not exist, error should be printed
10) -dump-level - again error if wrong value, document possible values if 
possible
11) please fix formatting of lto-dump so that it explains which suboptions are 
possible:

$ gcov-tool --help
Usage: gcov-tool [OPTION]... SUB_COMMAND [OPTION]...

Offline tool to handle gcda counts

  -h, --helpPrint this help, then exit
  -v, --version Print version number, then exit
  merge [options]   Merge coverage file contents
-o, --output   Output directory
-v, --verbose   Verbose mode
-w, --weight Set weights (float point values)
  rewrite [options]Rewrite coverage file contents
-n, --normalizeNormalize the profile
-o, --output   Output directory
-s, --scale   Scale the profile counters
-v, --verbose   Verbose mode
  overlap [options] Compute the overlap of two profiles
-f, --function  Print function level info
-F, --fullname  Print full filename
-h, --hotonly   Only print info for hot 
objects/functions
-o, --objectPrint object level info
-t , --hot_threshold  Set the threshold for hotness
-v, --verbose   Verbose mode

12) Do not name it in documentation 'lto-dump-tool', use simply 'lto-dump'.
13) make sure man page is generated for lto-dump
14) I noticed that you smashed some whitespaces for files where you didn't do 
any
changes: gcc/tree.c, lto.c(do_whole_program_analysis) and other places
15) test the tool on a bigger program built with LTO, ideally for both LGEN and 
also
LTRANS files
16) The last bigger challenge is the option handling, we currently participate 
in lto/lang.opt.
Ideally I would prefer using standard mechanism getopt_long, take a look at 
gcov-dump.c.
Can you please investigate that.

Anyway, thank you for working on that. I hope we can send a patch submission 
into GCC's trunk soon.
Martin

Re: [GSOC] LTO dump tool project - feedback

[Hrishikesh Kulkarni]

Hi,

Thanks for inputs and feedback. As per feedback, I have made all the
corrections/changes to the best of my understanding. Please find
details of the same given below.:
1) options of lto-dump:
a) removed the no-demangle command line option as it is default.
b) exit added after every dump. (to make it execute separately)
c) Made necessary change to consider single occurrence of object file
even if there are multiple occurrences.
d) -help option added.
e) alpha-sort renamed as name-sort,
flag_lto_alpha_sort renamed as flag_lto_name_sort,
alpha_compare() renamed as name_compare().

2) output formatting:
a) All '\t' replaced with (%10d) format.
b) Made necessary changes to remove extra output.
c) All list headers unified in a way that first letter is capital.
d) Made changes so that all used trees are printed. For gimple stats I
tried configuring with --enable-gather-detailed-mem-stats which worked
for me.
e) TDF_NONE made default level, -dump-body= can be invoked without -dump-level=
f)Renamed the command line options as -dump-body=, -dump-level=

3) written source code:
a) Deleted the header "gt-lto-lto.h" from lto.c and lto-dump.c and
added to lto-common.c
b) Modified parse_dump_option() and used in dumpfile.c.
c) Unnecessary code from lto_main() in lto-dump.c deleted.
e) Shifted all the functionalities used exclusively in lto.c from
lto-common.c to lto.c.
f) Used stdout instead of stderr.
g) Added/rewritten comments for all functions and structs and also for
lto_main().

4) misc:
a) Tried to modify make file for 'make install' of lto-dump. (diff
file attached)
b) Documented the lto-dump-tool command line options in
lto-dump-tool.texi could not link it in makefile. (diff file attached)
d) Removed all extra headers from lto-dump.c, added year of creation
and file comments.

I have pushed all the changes to the branch lto-dump-tool-v4.

I am facing some issue while modifying the Makefile for the points 4.a
and 4.b. Please find the diff file for the same attached herewith.

Thanks and Regards,

Hrishikesh

On Wed, Aug 1, 2018 at 6:59 PM, Martin Liška  wrote:
> Hi.
>
> I decided to come up with a new sub-thread that will be linked
> to a root of email discussion. First, thank you for working on
> the project and there's a feedback that I can provide now:
>
> 1) options of lto-dump:
>a) no-demangle - does not make sense because it's default
>b) you should exit after one command, you probably don't want to support:
>-list bzlib.o -tree-stats
>c) following should be maybe handled:
>   $ lto-dump -list bzlib.o bzlib.o
>
> bzlib.c:468:5: note: previously defined here
> bzlib.c:407:5: error: ‘BZ2_bzCompress’ has already been defined
>  int BZ_API(BZ2_bzCompress) ( bz_stream *strm, int action )
>  ^
> bzlib.c:407:5: note: previously defined here
> bzlib.c:148:5: error: ‘BZ2_bzCompressInit’ has already been defined
>  int BZ_API(BZ2_bzCompressInit)
>
>d) you should add --help option, take a look at gcov-dump --help, or gcov 
> --help,
>   or gcov-tool --help.
>e) alpha-sort - maybe name-sort, or alphabetic-sort?
>
> 2) output formatting
>a) you mix usage of tabulars and fixed columns (%10d), please use the later
>   at all places
>b) I see a lot of extra output when using the tool:
> ...
> Reading object files: bzlib.o {GC start 2164k}
> Reading the callgraph
> Merging declarations
> Reading summaries
> Reading function bodies:
> Performing interprocedural optimizations
> in:BZ2_bzCompressEnd 
> in:BZ2_bzDecompressEnd  
> Assembling 
> functions:
>add_pair_to_block in:add_pair_to_block 
> default_bzfree in:default_bzfree default_bzalloc in:default_bzalloc 
> handle_compress.isra.2 in:handle_compress.isra.2 in:copy_output_until_stop 
> in:copy_input_until_stop BZ2_bz__AssertH__fail in:BZ2_bz__AssertH__fail 
> BZ2_bzCompressInit in:BZ2_bzCompressInit BZ2_bzCompress in:BZ2_bzCompress 
> BZ2_bzCompressEnd BZ2_bzDecompressInit in:BZ2_bzDecompressInit BZ2_indexIntoF 
> in:BZ2_indexIntoF BZ2_bzDecompress in:BZ2_bzDecompress 
> in:unRLE_obuf_to_output_SMALL in:unRLE_obuf_to_output_FAST {GC 5331k -> 
> 2747k} BZ2_bzDecompressEnd BZ2_bzWriteOpen in:BZ2_bzWriteOpen 
> in:BZ2_bzWriteOpen.part.3 BZ2_bzWrite in:BZ2_bzWrite in:BZ2_bzWrite.part.4 
> BZ2_bzWriteClose64 in:BZ2_bzWriteClose64 in:BZ2_bzWriteClose64.part.5 
> BZ2_bzWriteClose in:BZ2_bzWriteClose BZ2_bzReadOpen in:BZ2_bzReadOpen 
> in:BZ2_bzReadOpen.part.6 {GC 5332k -> 2307k} bzopen_or_bzdopen 
> in:bzopen_or_bzdopen BZ2_bzReadClose in:BZ2_bzReadClose 
> in:BZ2_bzReadClose.part.7 BZ2_bzRead in:BZ2_bzRead in:BZ2_bzRead.part.8 
> in:myfeof BZ2_bzReadGetUnused in:BZ2_bzReadGetUnused 
> in:BZ2_bzReadGetUnused.part.9 BZ2_bzBuffToBuffCompress 
> in:BZ2_bzBuffToBuffCompress BZ2_bzBuffToBuffDecompress 
> in:BZ2_bzBuffToBuffDecompress BZ2_bzlibVersion in:BZ2_bzlibVersion BZ2_bzopen 
> in:BZ2_bzopen BZ2_bzdopen in:BZ2_bzdopen BZ2_bzread in:BZ2_bzread 
> in:BZ2_bzread.part.10 BZ2_bzwrite in:BZ2_bzwrite 

Re: [GSOC] LTO dump tool project

[Hrishikesh Kulkarni]

Hi,

I tried doing as suggested

+  dfi.pflags = 0;
+  dump_switch_p_1 (arg, , false);

1.>  the value of dfi.pflags is not changing even if different command
line options are passed like -fdump-blocks or -fdump-vops

2.> what is the significance of bool doglob?

Please find the diff file attached herewith.

Please advise.

Hrishikesh

On Tue, Jul 17, 2018 at 6:30 PM, Martin Liška  wrote:
> On 07/16/2018 05:44 PM, Hrishikesh Kulkarni wrote:
>> Hi,
>>
>> As suggested I have created command line option -optimized=[none,
>> blocks, stats, vops] to dump the respective gimple bodies of all
>> functions.
>>
>> for example:
>>
>> -optimized=blocks will dump
>
>
> Hi.
>
> The name does not make much sense and you removed option that
> limited function name. So instead I would create something like:
>
> -fdump-body=foo
> and
> -fdump-level=optimized
>
> I don't like how you do manual parsing in:
> +  if (!strcmp (flag_optimized, "blocks"))
> +flags = TDF_BLOCKS;
> +  else if (!strcmp (flag_optimized, "stats"))
> +flags = TDF_STATS;
> +  else if (!strcmp (flag_optimized, "vops"))
> +flags = TDF_VOPS;
> +  else if (!strcmp (flag_optimized, "none"))
> +flags = TDF_NONE;
>
> As I wrote in previous email, take a look how it's done
> in dump_switch_p_1 (const char *arg, struct dump_file_info *dfi, bool doglob)
> and reuse that functionality.
>
> Martin
>
>>
>> Gimple body of function: main
>> main ()
>> {
>> ;;   basic block 2, loop depth 0
>> ;;pred:   ENTRY
>>   printf ("%d", 8);
>>   return 0;
>> ;;succ:   EXIT
>>
>> }
>>
>>
>> Gimple body of function: bar
>> bar (int a, int b, int cond)
>> {
>>   int ret;
>>
>> ;;   basic block 2, loop depth 0
>> ;;pred:   ENTRY
>>   if (cond_2(D) != 0)
>> goto ; [50.00%]
>>   else
>> goto ; [50.00%]
>> ;;succ:   3
>> ;;4
>>
>> ;;   basic block 3, loop depth 0
>> ;;pred:   2
>>   ret_5 = a_3(D) + b_4(D);
>>   goto ; [100.00%]
>> ;;succ:   5
>>
>> ;;   basic block 4, loop depth 0
>> ;;pred:   2
>>   ret_6 = a_3(D) - b_4(D);
>> ;;succ:   5
>>
>> ;;   basic block 5, loop depth 0
>> ;;pred:   3
>> ;;4
>>   # ret_1 = PHI 
>>   return ret_1;
>> ;;succ:   EXIT
>>
>> }
>>
>>
>> Gimple body of function: foo
>> foo (int a, int b)
>> {
>> ;;   basic block 2, loop depth 0
>> ;;pred:   ENTRY
>>   _3 = a_1(D) + b_2(D);
>>   return _3;
>> ;;succ:   EXIT
>>
>> }
>>
>> I have pushed the changes to the repo. Please find the diff file
>> attached herewith.
>>
>> Regards,
>>
>> Hrishikesh
>>
>> On Fri, Jul 13, 2018 at 2:47 PM, Martin Liška  wrote:
>>> On 07/12/2018 08:05 PM, Hrishikesh Kulkarni wrote:
 Hi,

 I have added command line options:

 -body=
 To dump gimple body (TDF_NONE) of specific function.

 -optimized-blocks=
 To dump gimple body (TDF_BLOCKS) of specific function.

 -optimized-stats=
 To dump gimple body (TDF_STATS) of specific function.

 -optimized-vops=
 To dump gimple body (TDF_VOPS) of specific function.
>>>
>>> Hi.
>>>
>>> Thanks for it. However I would expect something more smart:
>>> -optimized=[vops,stats,block]. Note that you should do similar
>>> what's done in: gcc/dumpfile.c
>>>
>>> int
>>> gcc::dump_manager::
>>> dump_switch_p_1 (const char *arg, struct dump_file_info *dfi, bool doglob)
>>>
>>> that will automatically parse   dump_flags_t flags;
>>>
>>> Then the copy will not be needed.
>>>

 for example:

 -body=foo  will dump

 Gimple body of function: foo
 foo (int a, int b)
 {
[local count: 1073741825]:
   _3 = a_1(D) + b_2(D);
   return _3;

 }


 -optimized-blocks=foo  will dump

 Gimple body of function: foo
 foo (int a, int b)
 {
 ;;   basic block 2, loop depth 0
 ;;pred:   ENTRY
   _3 = a_1(D) + b_2(D);
   return _3;
 ;;succ:   EXIT

 }


 -optimized-stats=foo  will dump

 Gimple body of function: foo
 foo (int a, int b)
 {
[local count: 1073741825]:
   _3 = a_1(D) + b_2(D);
   return _3;

 }


 -optimized-vops=foo  will dump

 Gimple body of function: foo
 foo (int a, int b)
 {
[local count: 1073741825]:
   _3 = a_1(D) + b_2(D);
   # VUSE <.MEM_4(D)>
   return _3;

 }

 I have pushed the changes to the current branch. Please find the diff
 file attached herewith.

 I have tried to follow the coding conventions as far as possible in
 this patch. Please let me know if I am missing out something so that I
 can improve the same while refactoring and clean up as suggested in
 the previous mail.
>>>
>>> As mentioned in the previous email, indentation level is 2. And every 8 
>>> spaces
>>> are replaced with a tabular. In our patch, you use indentation level equal 
>>> to
>>> one tab, which results 

Re: [GSOC] LTO dump tool project

[Martin Liška]

On 07/16/2018 05:44 PM, Hrishikesh Kulkarni wrote:
> Hi,
> 
> As suggested I have created command line option -optimized=[none,
> blocks, stats, vops] to dump the respective gimple bodies of all
> functions.
> 
> for example:
> 
> -optimized=blocks will dump


Hi.

The name does not make much sense and you removed option that
limited function name. So instead I would create something like:

-fdump-body=foo
and
-fdump-level=optimized

I don't like how you do manual parsing in:
+  if (!strcmp (flag_optimized, "blocks"))
+flags = TDF_BLOCKS;
+  else if (!strcmp (flag_optimized, "stats"))
+flags = TDF_STATS;
+  else if (!strcmp (flag_optimized, "vops"))
+flags = TDF_VOPS;
+  else if (!strcmp (flag_optimized, "none"))
+flags = TDF_NONE;

As I wrote in previous email, take a look how it's done
in dump_switch_p_1 (const char *arg, struct dump_file_info *dfi, bool doglob)
and reuse that functionality.

Martin

> 
> Gimple body of function: main
> main ()
> {
> ;;   basic block 2, loop depth 0
> ;;pred:   ENTRY
>   printf ("%d", 8);
>   return 0;
> ;;succ:   EXIT
> 
> }
> 
> 
> Gimple body of function: bar
> bar (int a, int b, int cond)
> {
>   int ret;
> 
> ;;   basic block 2, loop depth 0
> ;;pred:   ENTRY
>   if (cond_2(D) != 0)
> goto ; [50.00%]
>   else
> goto ; [50.00%]
> ;;succ:   3
> ;;4
> 
> ;;   basic block 3, loop depth 0
> ;;pred:   2
>   ret_5 = a_3(D) + b_4(D);
>   goto ; [100.00%]
> ;;succ:   5
> 
> ;;   basic block 4, loop depth 0
> ;;pred:   2
>   ret_6 = a_3(D) - b_4(D);
> ;;succ:   5
> 
> ;;   basic block 5, loop depth 0
> ;;pred:   3
> ;;4
>   # ret_1 = PHI 
>   return ret_1;
> ;;succ:   EXIT
> 
> }
> 
> 
> Gimple body of function: foo
> foo (int a, int b)
> {
> ;;   basic block 2, loop depth 0
> ;;pred:   ENTRY
>   _3 = a_1(D) + b_2(D);
>   return _3;
> ;;succ:   EXIT
> 
> }
> 
> I have pushed the changes to the repo. Please find the diff file
> attached herewith.
> 
> Regards,
> 
> Hrishikesh
> 
> On Fri, Jul 13, 2018 at 2:47 PM, Martin Liška  wrote:
>> On 07/12/2018 08:05 PM, Hrishikesh Kulkarni wrote:
>>> Hi,
>>>
>>> I have added command line options:
>>>
>>> -body=
>>> To dump gimple body (TDF_NONE) of specific function.
>>>
>>> -optimized-blocks=
>>> To dump gimple body (TDF_BLOCKS) of specific function.
>>>
>>> -optimized-stats=
>>> To dump gimple body (TDF_STATS) of specific function.
>>>
>>> -optimized-vops=
>>> To dump gimple body (TDF_VOPS) of specific function.
>>
>> Hi.
>>
>> Thanks for it. However I would expect something more smart:
>> -optimized=[vops,stats,block]. Note that you should do similar
>> what's done in: gcc/dumpfile.c
>>
>> int
>> gcc::dump_manager::
>> dump_switch_p_1 (const char *arg, struct dump_file_info *dfi, bool doglob)
>>
>> that will automatically parse   dump_flags_t flags;
>>
>> Then the copy will not be needed.
>>
>>>
>>> for example:
>>>
>>> -body=foo  will dump
>>>
>>> Gimple body of function: foo
>>> foo (int a, int b)
>>> {
>>>[local count: 1073741825]:
>>>   _3 = a_1(D) + b_2(D);
>>>   return _3;
>>>
>>> }
>>>
>>>
>>> -optimized-blocks=foo  will dump
>>>
>>> Gimple body of function: foo
>>> foo (int a, int b)
>>> {
>>> ;;   basic block 2, loop depth 0
>>> ;;pred:   ENTRY
>>>   _3 = a_1(D) + b_2(D);
>>>   return _3;
>>> ;;succ:   EXIT
>>>
>>> }
>>>
>>>
>>> -optimized-stats=foo  will dump
>>>
>>> Gimple body of function: foo
>>> foo (int a, int b)
>>> {
>>>[local count: 1073741825]:
>>>   _3 = a_1(D) + b_2(D);
>>>   return _3;
>>>
>>> }
>>>
>>>
>>> -optimized-vops=foo  will dump
>>>
>>> Gimple body of function: foo
>>> foo (int a, int b)
>>> {
>>>[local count: 1073741825]:
>>>   _3 = a_1(D) + b_2(D);
>>>   # VUSE <.MEM_4(D)>
>>>   return _3;
>>>
>>> }
>>>
>>> I have pushed the changes to the current branch. Please find the diff
>>> file attached herewith.
>>>
>>> I have tried to follow the coding conventions as far as possible in
>>> this patch. Please let me know if I am missing out something so that I
>>> can improve the same while refactoring and clean up as suggested in
>>> the previous mail.
>>
>> As mentioned in the previous email, indentation level is 2. And every 8 
>> spaces
>> are replaced with a tabular. In our patch, you use indentation level equal to
>> one tab, which results in indentation level 8.
>>
>> Martin
>>
>>>
>>> Regards,
>>>
>>> Hrishikesh
>>>
>>> On Wed, Jul 11, 2018 at 12:10 AM, Hrishikesh Kulkarni
>>>  wrote:
 Hi,

 Thanks for suggestions. I would start working on these points and will
 try to complete as early as possible.

 Regards,

 Hrishikesh

 On Mon, Jul 9, 2018 at 2:04 PM, Martin Liška  wrote:
> On 07/09/2018 09:50 AM, Hrishikesh Kulkarni wrote:
>> Hi,
>>
>> The command line option -gimple-stats will dump the statistics of
>> gimple statements.
>>
>> For example:
>>

Re: [GSOC] LTO dump tool project

[Hrishikesh Kulkarni]

Hi,

As suggested I have created command line option -optimized=[none,
blocks, stats, vops] to dump the respective gimple bodies of all
functions.

for example:

-optimized=blocks will dump

Gimple body of function: main
main ()
{
;;   basic block 2, loop depth 0
;;pred:   ENTRY
  printf ("%d", 8);
  return 0;
;;succ:   EXIT

}


Gimple body of function: bar
bar (int a, int b, int cond)
{
  int ret;

;;   basic block 2, loop depth 0
;;pred:   ENTRY
  if (cond_2(D) != 0)
goto ; [50.00%]
  else
goto ; [50.00%]
;;succ:   3
;;4

;;   basic block 3, loop depth 0
;;pred:   2
  ret_5 = a_3(D) + b_4(D);
  goto ; [100.00%]
;;succ:   5

;;   basic block 4, loop depth 0
;;pred:   2
  ret_6 = a_3(D) - b_4(D);
;;succ:   5

;;   basic block 5, loop depth 0
;;pred:   3
;;4
  # ret_1 = PHI 
  return ret_1;
;;succ:   EXIT

}


Gimple body of function: foo
foo (int a, int b)
{
;;   basic block 2, loop depth 0
;;pred:   ENTRY
  _3 = a_1(D) + b_2(D);
  return _3;
;;succ:   EXIT

}

I have pushed the changes to the repo. Please find the diff file
attached herewith.

Regards,

Hrishikesh

On Fri, Jul 13, 2018 at 2:47 PM, Martin Liška  wrote:
> On 07/12/2018 08:05 PM, Hrishikesh Kulkarni wrote:
>> Hi,
>>
>> I have added command line options:
>>
>> -body=
>> To dump gimple body (TDF_NONE) of specific function.
>>
>> -optimized-blocks=
>> To dump gimple body (TDF_BLOCKS) of specific function.
>>
>> -optimized-stats=
>> To dump gimple body (TDF_STATS) of specific function.
>>
>> -optimized-vops=
>> To dump gimple body (TDF_VOPS) of specific function.
>
> Hi.
>
> Thanks for it. However I would expect something more smart:
> -optimized=[vops,stats,block]. Note that you should do similar
> what's done in: gcc/dumpfile.c
>
> int
> gcc::dump_manager::
> dump_switch_p_1 (const char *arg, struct dump_file_info *dfi, bool doglob)
>
> that will automatically parse   dump_flags_t flags;
>
> Then the copy will not be needed.
>
>>
>> for example:
>>
>> -body=foo  will dump
>>
>> Gimple body of function: foo
>> foo (int a, int b)
>> {
>>[local count: 1073741825]:
>>   _3 = a_1(D) + b_2(D);
>>   return _3;
>>
>> }
>>
>>
>> -optimized-blocks=foo  will dump
>>
>> Gimple body of function: foo
>> foo (int a, int b)
>> {
>> ;;   basic block 2, loop depth 0
>> ;;pred:   ENTRY
>>   _3 = a_1(D) + b_2(D);
>>   return _3;
>> ;;succ:   EXIT
>>
>> }
>>
>>
>> -optimized-stats=foo  will dump
>>
>> Gimple body of function: foo
>> foo (int a, int b)
>> {
>>[local count: 1073741825]:
>>   _3 = a_1(D) + b_2(D);
>>   return _3;
>>
>> }
>>
>>
>> -optimized-vops=foo  will dump
>>
>> Gimple body of function: foo
>> foo (int a, int b)
>> {
>>[local count: 1073741825]:
>>   _3 = a_1(D) + b_2(D);
>>   # VUSE <.MEM_4(D)>
>>   return _3;
>>
>> }
>>
>> I have pushed the changes to the current branch. Please find the diff
>> file attached herewith.
>>
>> I have tried to follow the coding conventions as far as possible in
>> this patch. Please let me know if I am missing out something so that I
>> can improve the same while refactoring and clean up as suggested in
>> the previous mail.
>
> As mentioned in the previous email, indentation level is 2. And every 8 spaces
> are replaced with a tabular. In our patch, you use indentation level equal to
> one tab, which results in indentation level 8.
>
> Martin
>
>>
>> Regards,
>>
>> Hrishikesh
>>
>> On Wed, Jul 11, 2018 at 12:10 AM, Hrishikesh Kulkarni
>>  wrote:
>>> Hi,
>>>
>>> Thanks for suggestions. I would start working on these points and will
>>> try to complete as early as possible.
>>>
>>> Regards,
>>>
>>> Hrishikesh
>>>
>>> On Mon, Jul 9, 2018 at 2:04 PM, Martin Liška  wrote:
 On 07/09/2018 09:50 AM, Hrishikesh Kulkarni wrote:
> Hi,
>
> The command line option -gimple-stats will dump the statistics of
> gimple statements.
>
> For example:
>
> $ ../stage1-build/gcc/lto-dump test_hello.o -gimple-stats
>
> will dump:
>
> GIMPLE statements
> Kind   Stmts  Bytes
> ---
> assignments3264
> phi nodes  1248
> conditionals   1 80
> everything else   12704
> ---
> Total 17   1296
> ---
>
> I have pushed the changes to the repo. Please find the diff file
> attached herewith.
>
> Regards,
>
> Hrishikesh

 Hi.

 Thanks for the work. I briefly took a look at the code and I would
 focus now directly on refactoring:

 - please make a new branch, first copy lto-dump.c file and all the
 Makefile needed stuff and commit that.
 - next please rebase (squash) all your patches which you have on top
 

Re: [GSOC] LTO dump tool project

[Martin Liška]

On 07/12/2018 08:05 PM, Hrishikesh Kulkarni wrote:
> Hi,
> 
> I have added command line options:
> 
> -body=
> To dump gimple body (TDF_NONE) of specific function.
> 
> -optimized-blocks=
> To dump gimple body (TDF_BLOCKS) of specific function.
> 
> -optimized-stats=
> To dump gimple body (TDF_STATS) of specific function.
> 
> -optimized-vops=
> To dump gimple body (TDF_VOPS) of specific function.

Hi.

Thanks for it. However I would expect something more smart:
-optimized=[vops,stats,block]. Note that you should do similar
what's done in: gcc/dumpfile.c

int
gcc::dump_manager::
dump_switch_p_1 (const char *arg, struct dump_file_info *dfi, bool doglob)

that will automatically parse   dump_flags_t flags;

Then the copy will not be needed.

> 
> for example:
> 
> -body=foo  will dump
> 
> Gimple body of function: foo
> foo (int a, int b)
> {
>[local count: 1073741825]:
>   _3 = a_1(D) + b_2(D);
>   return _3;
> 
> }
> 
> 
> -optimized-blocks=foo  will dump
> 
> Gimple body of function: foo
> foo (int a, int b)
> {
> ;;   basic block 2, loop depth 0
> ;;pred:   ENTRY
>   _3 = a_1(D) + b_2(D);
>   return _3;
> ;;succ:   EXIT
> 
> }
> 
> 
> -optimized-stats=foo  will dump
> 
> Gimple body of function: foo
> foo (int a, int b)
> {
>[local count: 1073741825]:
>   _3 = a_1(D) + b_2(D);
>   return _3;
> 
> }
> 
> 
> -optimized-vops=foo  will dump
> 
> Gimple body of function: foo
> foo (int a, int b)
> {
>[local count: 1073741825]:
>   _3 = a_1(D) + b_2(D);
>   # VUSE <.MEM_4(D)>
>   return _3;
> 
> }
> 
> I have pushed the changes to the current branch. Please find the diff
> file attached herewith.
> 
> I have tried to follow the coding conventions as far as possible in
> this patch. Please let me know if I am missing out something so that I
> can improve the same while refactoring and clean up as suggested in
> the previous mail.

As mentioned in the previous email, indentation level is 2. And every 8 spaces
are replaced with a tabular. In our patch, you use indentation level equal to
one tab, which results in indentation level 8.

Martin

> 
> Regards,
> 
> Hrishikesh
> 
> On Wed, Jul 11, 2018 at 12:10 AM, Hrishikesh Kulkarni
>  wrote:
>> Hi,
>>
>> Thanks for suggestions. I would start working on these points and will
>> try to complete as early as possible.
>>
>> Regards,
>>
>> Hrishikesh
>>
>> On Mon, Jul 9, 2018 at 2:04 PM, Martin Liška  wrote:
>>> On 07/09/2018 09:50 AM, Hrishikesh Kulkarni wrote:
 Hi,

 The command line option -gimple-stats will dump the statistics of
 gimple statements.

 For example:

 $ ../stage1-build/gcc/lto-dump test_hello.o -gimple-stats

 will dump:

 GIMPLE statements
 Kind   Stmts  Bytes
 ---
 assignments3264
 phi nodes  1248
 conditionals   1 80
 everything else   12704
 ---
 Total 17   1296
 ---

 I have pushed the changes to the repo. Please find the diff file
 attached herewith.

 Regards,

 Hrishikesh
>>>
>>> Hi.
>>>
>>> Thanks for the work. I briefly took a look at the code and I would
>>> focus now directly on refactoring:
>>>
>>> - please make a new branch, first copy lto-dump.c file and all the
>>> Makefile needed stuff and commit that.
>>> - next please rebase (squash) all your patches which you have on top
>>> of it; you did some formatting corrections and it's very hard to read
>>> - please fix coding style, it's mentioned here: 
>>> https://gcc.gnu.org/codingconventions.html
>>> the most problematic is usage of horizontal white spaces. We use 2 spaces
>>> for indentation level, and 8 spaces are replaced with a tabular; without 
>>> that reading your
>>> code is very hard for me
>>> - then please start refactoring functionality that is copied from lto.c and 
>>> put shared
>>> stuff into a header file that will be used by lto.c and lto-dump.c.
>>>
>>> Other observations:
>>> - you use "\t\t%s\t\t%s\t\t%s" formats for prints; I think it would be 
>>> better to
>>> use fixed strings with spaces, try %20s. It's probably also used by tools 
>>> like nm or objdump
>>> - come up with more specific name for 'entry' and 'compare'
>>> - 'entry' should have functions that will print names, ... according to 
>>> options
>>> (flag_lto_dump_demangle, ...); you can have overrides for functions and 
>>> variables
>>> - I would first put all symbols into the vector and then I would print it 
>>> on a single place
>>> - consider using vec from vec.h, hash_map from hash-map.h instead of std:: 
>>> variants
>>> - exit after functions like dump_list, dump_symbol,...
>>> - remove dummy 'dump' function
>>>
>>> Martin
>>>

 On Thu, Jul 5, 2018 at 10:41 PM, Hrishikesh Kulkarni
  wrote:
> Hi,
>
> I 

Re: [GSOC] LTO dump tool project

[Hrishikesh Kulkarni]

Hi,

Thanks for suggestions. I would start working on these points and will
try to complete as early as possible.

Regards,

Hrishikesh

On Mon, Jul 9, 2018 at 2:04 PM, Martin Liška  wrote:
> On 07/09/2018 09:50 AM, Hrishikesh Kulkarni wrote:
>> Hi,
>>
>> The command line option -gimple-stats will dump the statistics of
>> gimple statements.
>>
>> For example:
>>
>> $ ../stage1-build/gcc/lto-dump test_hello.o -gimple-stats
>>
>> will dump:
>>
>> GIMPLE statements
>> Kind   Stmts  Bytes
>> ---
>> assignments3264
>> phi nodes  1248
>> conditionals   1 80
>> everything else   12704
>> ---
>> Total 17   1296
>> ---
>>
>> I have pushed the changes to the repo. Please find the diff file
>> attached herewith.
>>
>> Regards,
>>
>> Hrishikesh
>
> Hi.
>
> Thanks for the work. I briefly took a look at the code and I would
> focus now directly on refactoring:
>
> - please make a new branch, first copy lto-dump.c file and all the
> Makefile needed stuff and commit that.
> - next please rebase (squash) all your patches which you have on top
> of it; you did some formatting corrections and it's very hard to read
> - please fix coding style, it's mentioned here: 
> https://gcc.gnu.org/codingconventions.html
> the most problematic is usage of horizontal white spaces. We use 2 spaces
> for indentation level, and 8 spaces are replaced with a tabular; without that 
> reading your
> code is very hard for me
> - then please start refactoring functionality that is copied from lto.c and 
> put shared
> stuff into a header file that will be used by lto.c and lto-dump.c.
>
> Other observations:
> - you use "\t\t%s\t\t%s\t\t%s" formats for prints; I think it would be better 
> to
> use fixed strings with spaces, try %20s. It's probably also used by tools 
> like nm or objdump
> - come up with more specific name for 'entry' and 'compare'
> - 'entry' should have functions that will print names, ... according to 
> options
> (flag_lto_dump_demangle, ...); you can have overrides for functions and 
> variables
> - I would first put all symbols into the vector and then I would print it on 
> a single place
> - consider using vec from vec.h, hash_map from hash-map.h instead of std:: 
> variants
> - exit after functions like dump_list, dump_symbol,...
> - remove dummy 'dump' function
>
> Martin
>
>>
>> On Thu, Jul 5, 2018 at 10:41 PM, Hrishikesh Kulkarni
>>  wrote:
>>> Hi,
>>>
>>> I have added new command line option:
>>> -objects
>>> which will dump size, offset and name of each section for all lto objects
>>>
>>> for example:
>>> $ ../stage1-build/gcc/lto-dump test_hello.o test.o -objects
>>>
>>> gives output:
>>> LTO object name: test_hello.o
>>>
>>> NO.OFFSETSIZESECTION NAME
>>>
>>> 16415.gnu.lto_.profile.a7add72ac123628
>>> 27955.gnu.lto_.icf.a7add72ac123628
>>> 3134134.gnu.lto_.jmpfuncs.a7add72ac123628
>>> 4268116.gnu.lto_.inline.a7add72ac123628
>>> 538424.gnu.lto_.pureconst.a7add72ac123628
>>> 6408306.gnu.lto_foo.a7add72ac123628
>>> 7714469.gnu.lto_bar.a7add72ac123628
>>> 81183345.gnu.lto_main.a7add72ac123628
>>> 9152888.gnu.lto_.symbol_nodes.a7add72ac123628
>>> 10161615.gnu.lto_.refs.a7add72ac123628
>>> 1116311205.gnu.lto_.decls.a7add72ac123628
>>> 122836109.gnu.lto_.symtab.a7add72ac123628
>>> 13294576.gnu.lto_.opts
>>>
>>> LTO object name: test.o
>>>
>>> NO.OFFSETSIZESECTION NAME
>>>
>>> 16415.gnu.lto_.profile.ffab9cb8eb84fc03
>>> 27930.gnu.lto_.icf.ffab9cb8eb84fc03
>>> 3109108.gnu.lto_.jmpfuncs.ffab9cb8eb84fc03
>>> 421762.gnu.lto_.inline.ffab9cb8eb84fc03
>>> 527921.gnu.lto_.pureconst.ffab9cb8eb84fc03
>>> 6300194.gnu.lto_koo.ffab9cb8eb84fc03
>>> 7494389.gnu.lto_gain.ffab9cb8eb84fc03
>>> 888377.gnu.lto_.symbol_nodes.ffab9cb8eb84fc03
>>> 996015.gnu.lto_.refs.ffab9cb8eb84fc03
>>> 10975966.gnu.lto_.decls.ffab9cb8eb84fc03
>>> 11194158.gnu.lto_.symtab.ffab9cb8eb84fc03
>>> 12199976.gnu.lto_.opts
>>>
>>>
>>> I have pushed the changes to the repo. Please find the diff file
>>> attached herewith.
>>>
>>> Regards,
>>>
>>> Hrishikesh
>>>
>>> On Thu, Jul 5, 2018 at 12:24 AM, Hrishikesh Kulkarni
>>>  wrote:
 Hi,

 I have:
 tried to do all 

Re: [GSOC] LTO dump tool project

[Martin Liška]

On 07/09/2018 09:50 AM, Hrishikesh Kulkarni wrote:
> Hi,
> 
> The command line option -gimple-stats will dump the statistics of
> gimple statements.
> 
> For example:
> 
> $ ../stage1-build/gcc/lto-dump test_hello.o -gimple-stats
> 
> will dump:
> 
> GIMPLE statements
> Kind   Stmts  Bytes
> ---
> assignments3264
> phi nodes  1248
> conditionals   1 80
> everything else   12704
> ---
> Total 17   1296
> ---
> 
> I have pushed the changes to the repo. Please find the diff file
> attached herewith.
> 
> Regards,
> 
> Hrishikesh

Hi.

Thanks for the work. I briefly took a look at the code and I would
focus now directly on refactoring:

- please make a new branch, first copy lto-dump.c file and all the
Makefile needed stuff and commit that.
- next please rebase (squash) all your patches which you have on top
of it; you did some formatting corrections and it's very hard to read
- please fix coding style, it's mentioned here: 
https://gcc.gnu.org/codingconventions.html
the most problematic is usage of horizontal white spaces. We use 2 spaces
for indentation level, and 8 spaces are replaced with a tabular; without that 
reading your
code is very hard for me
- then please start refactoring functionality that is copied from lto.c and put 
shared
stuff into a header file that will be used by lto.c and lto-dump.c.

Other observations:
- you use "\t\t%s\t\t%s\t\t%s" formats for prints; I think it would be better to
use fixed strings with spaces, try %20s. It's probably also used by tools like 
nm or objdump
- come up with more specific name for 'entry' and 'compare'
- 'entry' should have functions that will print names, ... according to options
(flag_lto_dump_demangle, ...); you can have overrides for functions and 
variables
- I would first put all symbols into the vector and then I would print it on a 
single place
- consider using vec from vec.h, hash_map from hash-map.h instead of std:: 
variants
- exit after functions like dump_list, dump_symbol,...
- remove dummy 'dump' function

Martin

> 
> On Thu, Jul 5, 2018 at 10:41 PM, Hrishikesh Kulkarni
>  wrote:
>> Hi,
>>
>> I have added new command line option:
>> -objects
>> which will dump size, offset and name of each section for all lto objects
>>
>> for example:
>> $ ../stage1-build/gcc/lto-dump test_hello.o test.o -objects
>>
>> gives output:
>> LTO object name: test_hello.o
>>
>> NO.OFFSETSIZESECTION NAME
>>
>> 16415.gnu.lto_.profile.a7add72ac123628
>> 27955.gnu.lto_.icf.a7add72ac123628
>> 3134134.gnu.lto_.jmpfuncs.a7add72ac123628
>> 4268116.gnu.lto_.inline.a7add72ac123628
>> 538424.gnu.lto_.pureconst.a7add72ac123628
>> 6408306.gnu.lto_foo.a7add72ac123628
>> 7714469.gnu.lto_bar.a7add72ac123628
>> 81183345.gnu.lto_main.a7add72ac123628
>> 9152888.gnu.lto_.symbol_nodes.a7add72ac123628
>> 10161615.gnu.lto_.refs.a7add72ac123628
>> 1116311205.gnu.lto_.decls.a7add72ac123628
>> 122836109.gnu.lto_.symtab.a7add72ac123628
>> 13294576.gnu.lto_.opts
>>
>> LTO object name: test.o
>>
>> NO.OFFSETSIZESECTION NAME
>>
>> 16415.gnu.lto_.profile.ffab9cb8eb84fc03
>> 27930.gnu.lto_.icf.ffab9cb8eb84fc03
>> 3109108.gnu.lto_.jmpfuncs.ffab9cb8eb84fc03
>> 421762.gnu.lto_.inline.ffab9cb8eb84fc03
>> 527921.gnu.lto_.pureconst.ffab9cb8eb84fc03
>> 6300194.gnu.lto_koo.ffab9cb8eb84fc03
>> 7494389.gnu.lto_gain.ffab9cb8eb84fc03
>> 888377.gnu.lto_.symbol_nodes.ffab9cb8eb84fc03
>> 996015.gnu.lto_.refs.ffab9cb8eb84fc03
>> 10975966.gnu.lto_.decls.ffab9cb8eb84fc03
>> 11194158.gnu.lto_.symtab.ffab9cb8eb84fc03
>> 12199976.gnu.lto_.opts
>>
>>
>> I have pushed the changes to the repo. Please find the diff file
>> attached herewith.
>>
>> Regards,
>>
>> Hrishikesh
>>
>> On Thu, Jul 5, 2018 at 12:24 AM, Hrishikesh Kulkarni
>>  wrote:
>>> Hi,
>>>
>>> I have:
>>> tried to do all the formatting and style corrections according to
>>> output given by check_GNU_style.py
>>> removed '-fdump-lto' prefix from the command line options
>>> added few necessary comments in the code
>>> added command line option -type-stats from previous branch (added a
>>> new percentage column to it)
>>> for e.g.
>>> integer_type3

Re: [GSOC] LTO dump tool project

[Hrishikesh Kulkarni]

Hi,

Thanks for suggestions. I have started incorporating them. As a first:

I have added command line options:
-print-size  to print the size of functions and variables
size of variables is in bits and size of functions is represented as
number of basic blocks.

-print-value  to print the value of initialization of global variables.

-size-sort  to sort the symbol names according to the size.

for example command line options:

 ../stage1-build/gcc/lto-dump test_hello.o -fdump-lto-list -print-size
-print-value -size-sort

the dump is:

Symbol Table
Name Type VisibilitySize Value

printf functiondefault   0
main functiondefault   3
foofunctiondefault   3
barfunctiondefault   6

z   variabledefault   897
k   variabledefault  325
p   variabledefault  32
4.40095367431640625e+0

I have also tried to make memory allocation dynamic to the best of my knowledge.
I have pushed the changes to the repo. Please find the diff file
attached herewith.

Regards,

Hrishikesh


On Fri, Jun 29, 2018 at 12:55 PM, Martin Liška  wrote:
> On 06/27/2018 10:06 PM, Hrishikesh Kulkarni wrote:
>> Hi,
>>
>> I have added new command line options:
>> -no-demangle -> for the default non demangled output
>> -no-sort -> for the list of symbols in order of their occurrence
>> -alpha-sort -> for the list of symbols in their alphabetical order
>> -reverse-sort -> for the list of symbols in reversed order
>> -defined-only -> for only the defined symbols
>
> Hi.
>
> Good progress.
>
>>
>> for example:
>>
>> ../stage1-build/gcc/lto-dump test_hello.o -fdump-lto-list -alpha-sort
>> -demangle -defined-only -reverse-sort
>
> Now as you have a separate tool (lto-dump), you can strip 'fdump-lto' prefix
> from the older options.
>
>>
>> will dump
>>
>> Symbol Table
>> Name Type Visibility Size
>> mainfunctiondefault
>> kvariabledefault
>> foofunctiondefault
>> barfunctiondefault
>>
>> It is a reversed alphabetical order of demangled symbol names which
>> have been defined(hence printf excluded).
>> Along with this I have also added all previous progress with reference
>> to symbol table to the new branch.
>>
>> For further options to add like -size-sort and -print-size I tried to
>> access size of the symbol with symtab node using
>> TREE_INT_CST_LOW(DECL_SIZE(node->decl));
>> but I am unable to do so.
>> So how should I proceed with it?
>
> Sent advises via instant messaging.
>
> Martin
>
>>
>> Please find the diff file attached herewith. I have also pushed the
>> changes to the new branch.
>>
>> Please advise,
>>
>> Hrishikesh>
>> On Wed, Jun 27, 2018 at 1:15 AM, Hrishikesh Kulkarni
>>  wrote:
>>> Hi,
>>>
>>> I have created another branch lto-dump-tool-improved as suggested.
>>> I have applied the patch for separation to lto-dump binary, made a few
>>> necessary changes in other files and it is running successfully.
>>> I will keep on adding previous work to this branch incrementally.
>>>
>>> Please find the diff file attached for dumping of TREE statistics and
>>> GIMPLE statistics.
>>>
>>> for example:
>>> (after configuring with --enable-gather-detailed-mem-stats)
>>> -fdump-lto-gimple-stats will dump
>>> GIMPLE statements
>>> Kind   Stmts  Bytes
>>> ---
>>> assignments0  0
>>> phi nodes  0  0
>>> conditionals   0  0
>>> everything else0  0
>>> ---
>>> Total  0  0
>>> ---
>>>
>>> -fdump-lto-tree-stats will dump
>>>
>>> Tree Statistics
>>>
>>> Kind   Nodes  Bytes
>>> 
>>> decls   4327 932672
>>> types   1531 257208
>>> blocks 0  0
>>> stmts  0  0
>>> refs   0  0
>>> exprs  4128
>>> constants 82   2060
>>> identifiers 4430 177200
>>> vecs  16  28544
>>> binfos 0  0
>>> ssa names  0  0
>>> constructors   0  0
>>> random kinds7301 291952
>>> lang_decl kinds0  0
>>> lang_type kinds0  0
>>> omp clauses0  0
>>> 
>>> Total  176911689764
>>>
>>>
>>>
>>> Please advise,
>>>
>>> Hrishikesh
>>>
>>> On Wed, Jun 27, 2018 at 

Re: [GSOC] LTO dump tool project

[Martin Liška]

On 06/27/2018 10:06 PM, Hrishikesh Kulkarni wrote:
> Hi,
> 
> I have added new command line options:
> -no-demangle -> for the default non demangled output
> -no-sort -> for the list of symbols in order of their occurrence
> -alpha-sort -> for the list of symbols in their alphabetical order
> -reverse-sort -> for the list of symbols in reversed order
> -defined-only -> for only the defined symbols

Hi.

Good progress.

> 
> for example:
> 
> ../stage1-build/gcc/lto-dump test_hello.o -fdump-lto-list -alpha-sort
> -demangle -defined-only -reverse-sort

Now as you have a separate tool (lto-dump), you can strip 'fdump-lto' prefix
from the older options.

> 
> will dump
> 
> Symbol Table
> Name Type Visibility Size
> mainfunctiondefault
> kvariabledefault
> foofunctiondefault
> barfunctiondefault
> 
> It is a reversed alphabetical order of demangled symbol names which
> have been defined(hence printf excluded).
> Along with this I have also added all previous progress with reference
> to symbol table to the new branch.
> 
> For further options to add like -size-sort and -print-size I tried to
> access size of the symbol with symtab node using
> TREE_INT_CST_LOW(DECL_SIZE(node->decl));
> but I am unable to do so.
> So how should I proceed with it?

Sent advises via instant messaging.

Martin

> 
> Please find the diff file attached herewith. I have also pushed the
> changes to the new branch.
> 
> Please advise,
> 
> Hrishikesh> 
> On Wed, Jun 27, 2018 at 1:15 AM, Hrishikesh Kulkarni
>  wrote:
>> Hi,
>>
>> I have created another branch lto-dump-tool-improved as suggested.
>> I have applied the patch for separation to lto-dump binary, made a few
>> necessary changes in other files and it is running successfully.
>> I will keep on adding previous work to this branch incrementally.
>>
>> Please find the diff file attached for dumping of TREE statistics and
>> GIMPLE statistics.
>>
>> for example:
>> (after configuring with --enable-gather-detailed-mem-stats)
>> -fdump-lto-gimple-stats will dump
>> GIMPLE statements
>> Kind   Stmts  Bytes
>> ---
>> assignments0  0
>> phi nodes  0  0
>> conditionals   0  0
>> everything else0  0
>> ---
>> Total  0  0
>> ---
>>
>> -fdump-lto-tree-stats will dump
>>
>> Tree Statistics
>>
>> Kind   Nodes  Bytes
>> 
>> decls   4327 932672
>> types   1531 257208
>> blocks 0  0
>> stmts  0  0
>> refs   0  0
>> exprs  4128
>> constants 82   2060
>> identifiers 4430 177200
>> vecs  16  28544
>> binfos 0  0
>> ssa names  0  0
>> constructors   0  0
>> random kinds7301 291952
>> lang_decl kinds0  0
>> lang_type kinds0  0
>> omp clauses0  0
>> 
>> Total  176911689764
>>
>>
>>
>> Please advise,
>>
>> Hrishikesh
>>
>> On Wed, Jun 27, 2018 at 1:00 AM, Hrishikesh Kulkarni
>>  wrote:
>>> Hi,
>>>
>>> I have created another branch lto-dump-tool-improved as suggested.
>>> I have applied the patch for separation to lto-dump binary, made a few
>>> necessary changes in other files and it is running successfully.
>>> I will keep on adding previous work to this branch incrementally.
>>>
>>> Please find the diff file attached for dumping of TREE statistics and GIMPLE
>>> statistics.
>>>
>>> for example:
>>> (after configuring with --enable-gather-detailed-mem-stats)
>>> -fdump-lto-gimple-stats will dump
>>> GIMPLE statements
>>> Kind   Stmts  Bytes
>>> ---
>>> assignments0  0
>>> phi nodes  0  0
>>> conditionals   0  0
>>> everything else0  0
>>> ---
>>> Total  0  0
>>> ---
>>>
>>> -fdump-lto-tree-stats will dump
>>>
>>> Tree Statistics
>>>
>>> Kind   Nodes  Bytes
>>> 
>>> decls   4327 932672
>>> types   1531 257208
>>> blocks 0  0
>>> stmts  0  0
>>> refs   0  0
>>> exprs  4128
>>> constants 82   

Re: [GSOC] LTO dump tool project

[Martin Liška]

On 06/26/2018 09:45 PM, Hrishikesh Kulkarni wrote:
> Hi,
> 
> I have created another branch lto-dump-tool-improved as suggested.
> I have applied the patch for separation to lto-dump binary, made a few
> necessary changes in other files and it is running successfully.
> I will keep on adding previous work to this branch incrementally.
> 
> Please find the diff file attached for dumping of TREE statistics and
> GIMPLE statistics.
> 
> for example:
> (after configuring with --enable-gather-detailed-mem-stats)
> -fdump-lto-gimple-stats will dump
> GIMPLE statements
> Kind   Stmts  Bytes
> ---
> assignments0  0
> phi nodes  0  0
> conditionals   0  0
> everything else0  0
> ---
> Total  0  0
> ---
> 
> -fdump-lto-tree-stats will dump
> 
> Tree Statistics
> 
> Kind   Nodes  Bytes
> 
> decls   4327 932672
> types   1531 257208
> blocks 0  0
> stmts  0  0
> refs   0  0
> exprs  4128
> constants 82   2060
> identifiers 4430 177200
> vecs  16  28544
> binfos 0  0
> ssa names  0  0
> constructors   0  0
> random kinds7301 291952
> lang_decl kinds0  0
> lang_type kinds0  0
> omp clauses0  0
> 
> Total  176911689764
> 
> 
> 
> Please advise,
> 
> Hrishikesh
> 
> On Wed, Jun 27, 2018 at 1:00 AM, Hrishikesh Kulkarni
>  wrote:
>> Hi,
>>
>> I have created another branch lto-dump-tool-improved as suggested.

Hi.

Great, it's now much more readable!

>> I have applied the patch for separation to lto-dump binary, made a few
>> necessary changes in other files and it is running successfully.
>> I will keep on adding previous work to this branch incrementally.

Good.

>>
>> Please find the diff file attached for dumping of TREE statistics and GIMPLE
>> statistics.
>>
>> for example:
>> (after configuring with --enable-gather-detailed-mem-stats)
>> -fdump-lto-gimple-stats will dump
>> GIMPLE statements
>> Kind   Stmts  Bytes
>> ---
>> assignments0  0
>> phi nodes  0  0
>> conditionals   0  0
>> everything else0  0
>> ---
>> Total  0  0
>> ---

I guess problem is that all numbers are zeros. Easiest what you can
do is to run normal GCC with -fmem-report and add '-wrapper gdb,--args'.
That will open GCC in debugger, that you can place a breapoint and you'll
see a backtrace.

>>
>> -fdump-lto-tree-stats will dump
>>
>> Tree Statistics
>>
>> Kind   Nodes  Bytes
>> 
>> decls   4327 932672
>> types   1531 257208
>> blocks 0  0
>> stmts  0  0
>> refs   0  0
>> exprs  4128
>> constants 82   2060
>> identifiers 4430 177200
>> vecs  16  28544
>> binfos 0  0
>> ssa names  0  0
>> constructors   0  0
>> random kinds7301 291952
>> lang_decl kinds0  0
>> lang_type kinds0  0
>> omp clauses0  0
>> 
>> Total  176911689764
>>

The output looks good for trees.

>>
>>
>> Please advise,

Next time, please specify where is problem for which you need advise ;)

Martin

>>
>> Hrishikesh
>>
>>
>> On Fri, Jun 22, 2018 at 2:29 PM, Martin Liška  wrote:
>>>
>>> On 06/18/2018 10:45 AM, Martin Jambor wrote:
 Hi,

 On Sun, Jun 17 2018, Hrishikesh Kulkarni wrote:
> Hi,
>
> I am trying to isolate the dump tool into real lto-dump tool. I have
> started with the copy of lto.c into lto-dump.c and done the
> changes to Make-lang.in and config-lang.in suggested by Martin (patch
> attached). However when I try to build, I get the following error:
>
> In file included from ../../gcc/gcc/lto/lto-dump.c:24:0:
>
> ../../gcc/gcc/coretypes.h:397:24: fatal error: insn-modes.h: No such
>
> file or directory
>
> compilation terminated.
>
>
> I am unable to find the 

Re: [GSOC] LTO dump tool project

[Martin Liška]

On 06/18/2018 10:45 AM, Martin Jambor wrote:
> Hi,
> 
> On Sun, Jun 17 2018, Hrishikesh Kulkarni wrote:
>> Hi,
>>
>> I am trying to isolate the dump tool into real lto-dump tool. I have
>> started with the copy of lto.c into lto-dump.c and done the
>> changes to Make-lang.in and config-lang.in suggested by Martin (patch
>> attached). However when I try to build, I get the following error:
>>
>> In file included from ../../gcc/gcc/lto/lto-dump.c:24:0:
>>
>> ../../gcc/gcc/coretypes.h:397:24: fatal error: insn-modes.h: No such
>>
>> file or directory
>>
>> compilation terminated.
>>
>>
>> I am unable to find the missing dependencies and would be grateful for
>> suggestions on how to resolve the issue.
> 
> insn-modes.h is one of header files which are generated at build time,
> you will find it in the gcc subdirectory of your build directory (as
> opposed to the source directory).
> 
> Martin
> 

Hi.

There's patch that works for me.
Needed dependency is here:

+lto/lto-dump.o: $(LTO_EXE)

It's bit artificial, but for now it works. Please start working
on separation of dump infrastructure to lto-dump.c. You'll need
to factor out common code shared in between lto.c and lto-dump.c.

Martin
diff --git a/gcc/lto/Make-lang.in b/gcc/lto/Make-lang.in
index 46950776dd2..7c1acdf6419 100644
--- a/gcc/lto/Make-lang.in
+++ b/gcc/lto/Make-lang.in
@@ -21,9 +21,12 @@
 
 # The name of the LTO compiler.
 LTO_EXE = lto1$(exeext)
+LTO_DUMP_EXE = lto-dump$(exeext)
 # The LTO-specific object files inclued in $(LTO_EXE).
 LTO_OBJS = lto/lto-lang.o lto/lto.o lto/lto-object.o attribs.o lto/lto-partition.o lto/lto-symtab.o
 lto_OBJS = $(LTO_OBJS)
+LTO_DUMP_OBJS = lto/lto-lang.o lto/lto-object.o attribs.o lto/lto-partition.o lto/lto-symtab.o lto/lto-dump.o
+lto_dump_OBJS = $(LTO_DUMP_OBJS)
 
 # this is only useful in a LTO bootstrap, but this does not work right
 # now. Should reenable after this is fixed, but only when LTO bootstrap
@@ -39,8 +42,8 @@ lto_OBJS = $(LTO_OBJS)
 
 # These hooks are used by the main GCC Makefile.  Consult that
 # Makefile for documentation.
-lto.all.cross: $(LTO_EXE)
-lto.start.encap: $(LTO_EXE)
+lto.all.cross: $(LTO_EXE) $(LTO_DUMP_EXE)
+lto.start.encap: $(LTO_EXE) $(LTO_DUMP_EXE)
 lto.rest.encap:
 lto.tags:
 lto.install-common:
@@ -60,7 +63,7 @@ lto.srcinfo:
 lto.install-plugin:
 
 lto.mostlyclean:
-	rm -f $(LTO_OBJS) $(LTO_EXE) lto1.fda
+	rm -f $(LTO_OBJS) $(LTO_EXE) lto1.fda $(LTO_DUMP_OBJS) $(LTO_DUMP_EXE) lto-dump.fda
 
 lto.clean:
 lto.distclean:
@@ -81,6 +84,12 @@ $(LTO_EXE): $(LTO_OBJS) $(BACKEND) $(LIBDEPS)
 	+$(LLINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ \
 		$(LTO_OBJS) $(BACKEND) $(BACKENDLIBS) $(LIBS)
 
+$(LTO_DUMP_EXE): $(LTO_EXE) $(LTO_DUMP_OBJS) $(BACKEND) $(LIBDEPS)
+	+$(LLINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ \
+		$(LTO_DUMP_OBJS) $(BACKEND) $(BACKENDLIBS) $(LIBS)
+
+lto/lto-dump.o: $(LTO_EXE)
+
 lto1.fda: ../prev-gcc/lto1$(exeext) ../prev-gcc/$(PERF_DATA)
 	$(CREATE_GCOV) -binary ../prev-gcc/lto1$(exeext) -gcov lto1.fda -profile ../prev-gcc/$(PERF_DATA) -gcov_version 1
 
diff --git a/gcc/lto/config-lang.in b/gcc/lto/config-lang.in
index 0b5a846e1ca..ada21681c6a 100644
--- a/gcc/lto/config-lang.in
+++ b/gcc/lto/config-lang.in
@@ -18,7 +18,7 @@
 # .
 
 language="lto"
-compilers="lto1\$(exeext)"
+compilers="lto1\$(exeext) lto-dump\$(exeext)"
 
 gtfiles="\$(srcdir)/lto/lto-tree.h \$(srcdir)/lto/lto-lang.c \$(srcdir)/lto/lto.c \$(srcdir)/lto/lto.h"
 

Re: [GSOC] LTO dump tool project

[Martin Liška]

Hi.

There were some questions from Hrishikesh about requested goals
of the project. Thus I would like to specify what I'm aware of:

1) symbol table
   - list all symbols
   - print details info about a symbol (symtab_node::debug)
   - print GIMPLE body of a function
 - I would like to see supporting levels what we have e.g.:

-fdump-tree-optimized-blocks
-fdump-tree-optimized-stats

It's defined in dumpfile.h:
enum dump_flag

   - I would like to see constructor of a global variable:
DECL_INITIAL (...), probably print_generic_expr will work

we can consider adding similar options seen in nm:

   --no-demangle
   Do not demangle low-level symbol names.  This is the default.

   -p
   --no-sort
   Do not bother to sort the symbols in any order; print them in the 
order encountered.
   -S
   --print-size
   Print both value and size of defined symbols for the "bsd" output 
style.  This option has no effect for object formats that do not record symbol 
sizes, unless --size-sort is also used in which case a calculated size is 
displayed.
   -r
   --reverse-sort
   Reverse the order of the sort (whether numeric or alphabetic); let 
the last come first.

   --defined-only
   Display only defined symbols for each object file.

   --size-sort
   Sort symbols by size.  For ELF objects symbol sizes are read from 
the ELF, for other object types the symbol sizes are computed as the difference 
between the value of the symbol and the value of the symbol with the next 
higher value.  If the "bsd" output
   format is used the size of the symbol is printed, rather than the 
value, and -S must be used in order both size and value to be printed.

It's just for inspiration, see man nm

2) statistics
   - GIMPLE and TREE statistics, similar to what we do for -fmem-report

3) LTO objects
   - we should list read files, archives, ... and print some stats about it

4) tree types
   - list types
   - print one (debug_tree) with different verbosity level, again 'enum 
dump_flag'

5) visualization
   - should be done, via -fdump-ipa-icf-graph, generates .dot file. Should be 
easy to use.

6) separation to lto-dump binary
   - here I can help, I'll cook a patch for it

I believe it's a series of small patches that can implement that. I hope you'll
invent even more options as you play with LTO.

Martin

Re: [GSOC] LTO dump tool project

[Martin Liška]

On 06/20/2018 07:23 PM, Hrishikesh Kulkarni wrote:
> Hi,
> 
> Please find the diff file for dumping tree type stats attached here with.
> 
> example:
> 
> $ ../stage1-build/gcc/lto1 test_hello.o -fdump-lto-tree-type-stats
> Reading object files: test_hello.o
> integer_type3
> pointer_type3
> array_type1
> function_type4
> 
> I have pushed the changes on Github repo.

Hi.

Good progress here. I would also dump statistics for GIMPLE statements.
If you configure gcc with  --enable-gather-detailed-mem-stats, you should
see:

./xgcc -B. /tmp/main.c -fmem-report -O2
...
GIMPLE statements
Kind   Stmts  Bytes
---
assignments6480
phi nodes  0  0
conditionals   8640
everything else   21   1368
---
Total 35   2488
...

Take a look at dump_gimple_statistics,   gimple_alloc_counts,
gimple_alloc_sizes.

We do the same for trees:

static uint64_t tree_code_counts[MAX_TREE_CODES];
uint64_t tree_node_counts[(int) all_kinds];
uint64_t tree_node_sizes[(int) all_kinds];

I believe the infrastructure should be shared.

Martin


> 
> Regards,
> 
> Hrishikesh
> 
> On Mon, Jun 18, 2018 at 2:15 PM, Martin Jambor  wrote:
>> Hi,
>>
>> On Sun, Jun 17 2018, Hrishikesh Kulkarni wrote:
>>> Hi,
>>>
>>> I am trying to isolate the dump tool into real lto-dump tool. I have
>>> started with the copy of lto.c into lto-dump.c and done the
>>> changes to Make-lang.in and config-lang.in suggested by Martin (patch
>>> attached). However when I try to build, I get the following error:
>>>
>>> In file included from ../../gcc/gcc/lto/lto-dump.c:24:0:
>>>
>>> ../../gcc/gcc/coretypes.h:397:24: fatal error: insn-modes.h: No such
>>>
>>> file or directory
>>>
>>> compilation terminated.
>>>
>>>
>>> I am unable to find the missing dependencies and would be grateful for
>>> suggestions on how to resolve the issue.
>>
>> insn-modes.h is one of header files which are generated at build time,
>> you will find it in the gcc subdirectory of your build directory (as
>> opposed to the source directory).
>>
>> Martin

Re: [GSOC] LTO dump tool project

[Hrishikesh Kulkarni]

Hi,

Please find the diff file for dumping tree type stats attached here with.

example:

$ ../stage1-build/gcc/lto1 test_hello.o -fdump-lto-tree-type-stats
Reading object files: test_hello.o
integer_type3
pointer_type3
array_type1
function_type4

I have pushed the changes on Github repo.

Regards,

Hrishikesh

On Mon, Jun 18, 2018 at 2:15 PM, Martin Jambor  wrote:
> Hi,
>
> On Sun, Jun 17 2018, Hrishikesh Kulkarni wrote:
>> Hi,
>>
>> I am trying to isolate the dump tool into real lto-dump tool. I have
>> started with the copy of lto.c into lto-dump.c and done the
>> changes to Make-lang.in and config-lang.in suggested by Martin (patch
>> attached). However when I try to build, I get the following error:
>>
>> In file included from ../../gcc/gcc/lto/lto-dump.c:24:0:
>>
>> ../../gcc/gcc/coretypes.h:397:24: fatal error: insn-modes.h: No such
>>
>> file or directory
>>
>> compilation terminated.
>>
>>
>> I am unable to find the missing dependencies and would be grateful for
>> suggestions on how to resolve the issue.
>
> insn-modes.h is one of header files which are generated at build time,
> you will find it in the gcc subdirectory of your build directory (as
> opposed to the source directory).
>
> Martin
diff --git a/gcc/lto/lang.opt b/gcc/lto/lang.opt
index c10c662..dd506c0 100644
--- a/gcc/lto/lang.opt
+++ b/gcc/lto/lang.opt
@@ -77,6 +77,9 @@ LTO Driver RejectNegative Joined Var(flag_lto_dump_symbol)
 demangle
 LTO Var(flag_lto_dump_demangle)
 
+fdump-lto-tree-type-stats
+LTO Var(flag_lto_dump_tree_type_stats)
+
 fdump-lto-body=
 LTO Driver RejectNegative Joined Var(flag_lto_dump_body)
 
diff --git a/gcc/lto/lto.c b/gcc/lto/lto.c
index afdb76a..760a796 100644
--- a/gcc/lto/lto.c
+++ b/gcc/lto/lto.c
@@ -1799,9 +1799,6 @@ lto_read_decls (struct lto_file_decl_data *decl_data, const void *data,
 	  data_in->location_cache.accept_location_cache ();
 
 	  bool seen_type = false;
-
-
-
 	  for (unsigned i = 0; i < len; ++i)
 	{
 	  tree t = streamer_tree_cache_get_tree (data_in->reader_cache,
@@ -1810,14 +1807,14 @@ lto_read_decls (struct lto_file_decl_data *decl_data, const void *data,
 		 chains.  */
 	  if (TYPE_P (t))
 		{ 
-  itr = stats.find(TREE_CODE(t));
-  if (itr == stats.end())
+  if (flag_lto_dump_tree_type_stats)
   {
-stats.insert(std :: pair  (TREE_CODE(t), 1));
-  }
-  else
-itr->second++;
-
+itr = stats.find(TREE_CODE(t));
+if (itr == stats.end())
+  stats.insert(std :: pair  (TREE_CODE(t), 1));
+else
+  itr->second++;
+  }  
 		  seen_type = true;
 		  num_prevailing_types++;
 		  lto_fixup_prevailing_type (t);
@@ -1865,10 +1862,9 @@ lto_read_decls (struct lto_file_decl_data *decl_data, const void *data,
 	}
 }
 fprintf(stderr, "\n");
-for (itr = stats.begin(); itr != stats.end(); ++itr)
-{
-  fprintf(stderr, "\t%s\t%d\n", get_tree_code_name(itr->first), itr->second );
-}
+if (flag_lto_dump_tree_type_stats)
+  for (itr = stats.begin(); itr != stats.end(); ++itr)
+fprintf(stderr, "\t%s\t%d\n", get_tree_code_name(itr->first), itr->second );
 
   data_in->location_cache.apply_location_cache ();
 

Re: [GSOC] LTO dump tool project

[Martin Jambor]

Hi,

On Sun, Jun 17 2018, Hrishikesh Kulkarni wrote:
> Hi,
>
> I am trying to isolate the dump tool into real lto-dump tool. I have
> started with the copy of lto.c into lto-dump.c and done the
> changes to Make-lang.in and config-lang.in suggested by Martin (patch
> attached). However when I try to build, I get the following error:
>
> In file included from ../../gcc/gcc/lto/lto-dump.c:24:0:
>
> ../../gcc/gcc/coretypes.h:397:24: fatal error: insn-modes.h: No such
>
> file or directory
>
> compilation terminated.
>
>
> I am unable to find the missing dependencies and would be grateful for
> suggestions on how to resolve the issue.

insn-modes.h is one of header files which are generated at build time,
you will find it in the gcc subdirectory of your build directory (as
opposed to the source directory).

Martin

Re: [GSOC] LTO dump tool project

[Hrishikesh Kulkarni]

Hi,

I am trying to isolate the dump tool into real lto-dump tool. I have
started with the copy of lto.c into lto-dump.c and done the
changes to Make-lang.in and config-lang.in suggested by Martin (patch
attached). However when I try to build, I get the following error:

In file included from ../../gcc/gcc/lto/lto-dump.c:24:0:

../../gcc/gcc/coretypes.h:397:24: fatal error: insn-modes.h: No such

file or directory

compilation terminated.


I am unable to find the missing dependencies and would be grateful for
suggestions on how to resolve the issue.

Please advise,

Regards,
Hrishikesh


On Wed, Jun 13, 2018 at 2:21 PM, Martin Liška  wrote:
> Hi.
>
> There's working patch that really generates lto-dump binary.
>
> Martin

Re: [GSOC] LTO dump tool project

[Martin Liška]

Hi.

There's working patch that really generates lto-dump binary.

Martin
diff --git a/gcc/lto/Make-lang.in b/gcc/lto/Make-lang.in
index 46950776dd2..502afe94851 100644
--- a/gcc/lto/Make-lang.in
+++ b/gcc/lto/Make-lang.in
@@ -21,10 +21,14 @@
 
 # The name of the LTO compiler.
 LTO_EXE = lto1$(exeext)
+LTO_DUMP_EXE = lto-dump$(exeext)
 # The LTO-specific object files inclued in $(LTO_EXE).
 LTO_OBJS = lto/lto-lang.o lto/lto.o lto/lto-object.o attribs.o lto/lto-partition.o lto/lto-symtab.o
 lto_OBJS = $(LTO_OBJS)
 
+LTO_DUMP_OBJS = lto/lto-lang.o lto/lto-dump.o lto/lto-object.o attribs.o lto/lto-partition.o lto/lto-symtab.o
+lto_dump_OBJS = $(LTO_DUMP_OBJS)
+
 # this is only useful in a LTO bootstrap, but this does not work right
 # now. Should reenable after this is fixed, but only when LTO bootstrap
 # is enabled.
@@ -39,8 +43,8 @@ lto_OBJS = $(LTO_OBJS)
 
 # These hooks are used by the main GCC Makefile.  Consult that
 # Makefile for documentation.
-lto.all.cross: $(LTO_EXE)
-lto.start.encap: $(LTO_EXE)
+lto.all.cross: $(LTO_EXE) $(LTO_DUMP_EXE)
+lto.start.encap: $(LTO_EXE) $(LTO_DUMP_EXE)
 lto.rest.encap:
 lto.tags:
 lto.install-common:
@@ -60,7 +64,7 @@ lto.srcinfo:
 lto.install-plugin:
 
 lto.mostlyclean:
-	rm -f $(LTO_OBJS) $(LTO_EXE) lto1.fda
+	rm -f $(LTO_DUMP_OBJS) $(LTO_DUMP_EXE) lto-dump.fda $(LTO_OBJS) $(LTO_EXE) lto1.fda
 
 lto.clean:
 lto.distclean:
@@ -81,6 +85,10 @@ $(LTO_EXE): $(LTO_OBJS) $(BACKEND) $(LIBDEPS)
 	+$(LLINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ \
 		$(LTO_OBJS) $(BACKEND) $(BACKENDLIBS) $(LIBS)
 
+$(LTO_DUMP_EXE): $(LTO_DUMP_OBJS) $(BACKEND) $(LIBDEPS)
+	+$(LLINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ \
+		$(LTO_DUMP_OBJS) $(BACKEND) $(BACKENDLIBS) $(LIBS)
+
 lto1.fda: ../prev-gcc/lto1$(exeext) ../prev-gcc/$(PERF_DATA)
 	$(CREATE_GCOV) -binary ../prev-gcc/lto1$(exeext) -gcov lto1.fda -profile ../prev-gcc/$(PERF_DATA) -gcov_version 1
 

Re: [GSOC] LTO dump tool project

[Martin Liška]

On 06/12/2018 06:22 PM, Hrishikesh Kulkarni wrote:

Hi,

I tried tweaking the make file. I am probably missing something. Please advise.


Hi.

Next time please send diff. It's easier to read it. You'll need something like:

diff --git a/gcc/lto/config-lang.in b/gcc/lto/config-lang.in
index 7cb7a7752a1..52e452af5f3 100644
--- a/gcc/lto/config-lang.in
+++ b/gcc/lto/config-lang.in
@@ -18,8 +18,8 @@
 # .
 
 language="lto"

-compilers="lto1\$(exeext)"
-stagestuff="lto1\$(exeext)"
+compilers="lto1\$(exeext) lto-dump\$(exeext)"
+stagestuff="lto1\$(exeext) lto-dump\$(exeext)"
 
 gtfiles="\$(srcdir)/lto/lto-tree.h \$(srcdir)/lto/lto-lang.c \$(srcdir)/lto/lto.c \$(srcdir)/lto/lto.h"
 
And please rename it to lto-dump.


Martin



Regards,

Hrishikesh

On Mon, Jun 11, 2018 at 1:36 PM, Martin Liška  wrote:

On 06/08/2018 07:16 PM, Hrishikesh Kulkarni wrote:

Hi,

-fdump-lto-body=foo
will dump gimple body of the function foo

foo (int a, int b)
{
[local count: 1073741825]:
   _3 = a_1(D) + b_2(D);
   return _3;

}

Please find the diff file attached herewith.

Regards,
Hrishikesh

On Fri, Jun 8, 2018 at 7:15 PM, Martin Liška  wrote:

On 06/08/2018 03:40 PM, Martin Liška wrote:

There's wrong declaration of the function in header file. I'll fix it soon
on trunk. Please carry on with following patch:


Fixed in r261327.

Martin


Hi.

Thanks for another new option. I have some comments:

1) remove these files from git branch:
diff --git a/gcc/cscope.out b/gcc/cscope.out
diff --git a/gcc/err b/gcc/err

2) You have repeated pattern:

FOR_EACH_SYMBOL (node)
   if (!strcmp (flag_lto_dump_symbol, node->name ()))
  some_action();

Let's come up with function symtab->find_symbol_by_name.

Martin

Re: [GSOC] LTO dump tool project

[Hrishikesh Kulkarni]

Hi,

I tried tweaking the make file. I am probably missing something. Please advise.

Regards,

Hrishikesh

On Mon, Jun 11, 2018 at 1:36 PM, Martin Liška  wrote:
> On 06/08/2018 07:16 PM, Hrishikesh Kulkarni wrote:
>> Hi,
>>
>> -fdump-lto-body=foo
>> will dump gimple body of the function foo
>>
>> foo (int a, int b)
>> {
>>[local count: 1073741825]:
>>   _3 = a_1(D) + b_2(D);
>>   return _3;
>>
>> }
>>
>> Please find the diff file attached herewith.
>>
>> Regards,
>> Hrishikesh
>>
>> On Fri, Jun 8, 2018 at 7:15 PM, Martin Liška  wrote:
>>> On 06/08/2018 03:40 PM, Martin Liška wrote:
 There's wrong declaration of the function in header file. I'll fix it soon
 on trunk. Please carry on with following patch:
>>>
>>> Fixed in r261327.
>>>
>>> Martin
>
> Hi.
>
> Thanks for another new option. I have some comments:
>
> 1) remove these files from git branch:
> diff --git a/gcc/cscope.out b/gcc/cscope.out
> diff --git a/gcc/err b/gcc/err
>
> 2) You have repeated pattern:
>
> FOR_EACH_SYMBOL (node)
>   if (!strcmp (flag_lto_dump_symbol, node->name ()))
>  some_action();
>
> Let's come up with function symtab->find_symbol_by_name.
>
> Martin


Make-lang.in
Description: Binary data

Re: [GSOC] LTO dump tool project

[Martin Liška]

On 06/08/2018 07:16 PM, Hrishikesh Kulkarni wrote:
> Hi,
> 
> -fdump-lto-body=foo
> will dump gimple body of the function foo
> 
> foo (int a, int b)
> {
>[local count: 1073741825]:
>   _3 = a_1(D) + b_2(D);
>   return _3;
> 
> }
> 
> Please find the diff file attached herewith.
> 
> Regards,
> Hrishikesh
> 
> On Fri, Jun 8, 2018 at 7:15 PM, Martin Liška  wrote:
>> On 06/08/2018 03:40 PM, Martin Liška wrote:
>>> There's wrong declaration of the function in header file. I'll fix it soon
>>> on trunk. Please carry on with following patch:
>>
>> Fixed in r261327.
>>
>> Martin

Hi.

Thanks for another new option. I have some comments:

1) remove these files from git branch:
diff --git a/gcc/cscope.out b/gcc/cscope.out
diff --git a/gcc/err b/gcc/err

2) You have repeated pattern:

FOR_EACH_SYMBOL (node)
  if (!strcmp (flag_lto_dump_symbol, node->name ()))
 some_action();

Let's come up with function symtab->find_symbol_by_name.

Martin

Re: [GSOC] LTO dump tool project

[Prathamesh Kulkarni]

On 8 June 2018 at 22:46, Hrishikesh Kulkarni  wrote:
> Hi,
>
> -fdump-lto-body=foo
> will dump gimple body of the function foo
>
> foo (int a, int b)
> {
>[local count: 1073741825]:
>   _3 = a_1(D) + b_2(D);
>   return _3;
>
> }
>
> Please find the diff file attached herewith.
@@ -53,10 +55,14 @@ dump_list ()
 fprintf (stderr, "\t\tName \t\tType \t\tVisibility\n");
  FOR_EACH_SYMBOL (node)
  {
- fprintf (stderr, "\n%20s",(flag_lto_dump_demangle)
- ? node->name (): node->dump_asm_name ());
+const char *x = strchr (node->asm_name (), '/');
+if (flag_lto_dump_demangle)
+ fprintf (stderr, "\n%20s", node->name ());
+ else
+ fprintf (stderr, "\n%20s", node->asm_name (),
+ node->asm_name ()-x);
Shouldn't this be:
fprintf (stderr, "\n%20.*s", (int) (x - node->asm_name ()), node->asm_name ()) ?
Also better to put strchr within else block since that's the only
place you seem to be using it.

Thanks,
Prathamesh
>
> Regards,
> Hrishikesh
>
> On Fri, Jun 8, 2018 at 7:15 PM, Martin Liška  wrote:
>> On 06/08/2018 03:40 PM, Martin Liška wrote:
>>> There's wrong declaration of the function in header file. I'll fix it soon
>>> on trunk. Please carry on with following patch:
>>
>> Fixed in r261327.
>>
>> Martin

Re: [GSOC] LTO dump tool project

[Hrishikesh Kulkarni]

Hi,

-fdump-lto-body=foo
will dump gimple body of the function foo

foo (int a, int b)
{
   [local count: 1073741825]:
  _3 = a_1(D) + b_2(D);
  return _3;

}

Please find the diff file attached herewith.

Regards,
Hrishikesh

On Fri, Jun 8, 2018 at 7:15 PM, Martin Liška  wrote:
> On 06/08/2018 03:40 PM, Martin Liška wrote:
>> There's wrong declaration of the function in header file. I'll fix it soon
>> on trunk. Please carry on with following patch:
>
> Fixed in r261327.
>
> Martin
diff --git a/gcc/lto-streamer-in.c b/gcc/lto-streamer-in.c
index 8529c82..8d20917 100644
--- a/gcc/lto-streamer-in.c
+++ b/gcc/lto-streamer-in.c
@@ -1320,7 +1320,6 @@ lto_read_body_or_constructor (struct lto_file_decl_data *file_data, struct symta
   /* Restore decl state */
   file_data->current_decl_state = file_data->global_decl_state;
 }
-
   lto_data_in_delete (data_in);
 }
 
diff --git a/gcc/lto/lang.opt b/gcc/lto/lang.opt
index a098797..c10c662 100644
--- a/gcc/lto/lang.opt
+++ b/gcc/lto/lang.opt
@@ -77,6 +77,9 @@ LTO Driver RejectNegative Joined Var(flag_lto_dump_symbol)
 demangle
 LTO Var(flag_lto_dump_demangle)
 
+fdump-lto-body=
+LTO Driver RejectNegative Joined Var(flag_lto_dump_body)
+
 fresolution=
 LTO Joined
 The resolution file.
diff --git a/gcc/lto/lto-dump.c b/gcc/lto/lto-dump.c
index e0becd1..687c9c9 100644
--- a/gcc/lto/lto-dump.c
+++ b/gcc/lto/lto-dump.c
@@ -24,6 +24,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "function.h"
 #include "basic-block.h"
 #include "tree.h"
+#include "tree-cfg.h"
 #include "gimple.h"
 #include "cgraph.h"
 #include "lto-streamer.h"
@@ -36,13 +37,14 @@ along with GCC; see the file COPYING3.  If not see
 #include "stdio.h"
 #include "lto.h"
 
+
 /* Dump everything.  */
-void 
+void
 dump ()
 {
 	fprintf(stderr, "\nHello World!\n");
 }
-	
+
 /* Dump variables and functions used in IL.  */
 void
 dump_list ()
@@ -53,10 +55,14 @@ dump_list ()
 fprintf (stderr, "\t\tName \t\tType \t\tVisibility\n");
 	FOR_EACH_SYMBOL (node)
 	{
-		fprintf (stderr, "\n%20s",(flag_lto_dump_demangle) 
-			? node->name (): node->dump_asm_name ());
+	const char *x = strchr (node->asm_name (), '/');
+	if (flag_lto_dump_demangle)
+			fprintf (stderr, "\n%20s", node->name ());
+		else
+			fprintf (stderr, "\n%20s", node->asm_name (), 
+node->asm_name ()-x);
 		fprintf (stderr, "%20s", node->dump_type_name ());
-		fprintf (stderr, "%20s\n", node->dump_visibility ());
+		fprintf (stderr, "%20s", node->dump_visibility ());
 	}
 }
 
@@ -67,13 +73,19 @@ dump_symbol ()
 	symtab_node *node;
 fprintf (stderr, "\t\tName \t\tType \t\tVisibility\n");
 	FOR_EACH_SYMBOL (node)
-	{
-		if (!strcmp(flag_lto_dump_symbol, node->name()))
+		if (!strcmp (flag_lto_dump_symbol, node->name ()))
+			node->debug ();
+}
+
+/* Dump gimple body of specific function.  */
+void
+dump_body ()
+{
+	cgraph_node *cnode;
+	FOR_EACH_FUNCTION (cnode)
+		if (!strcmp (cnode->name (), flag_lto_dump_body))
 		{
-			fprintf (stderr, "\n%20s",(flag_lto_dump_demangle) 
-? node->name (): node->dump_asm_name ());
-		fprintf (stderr, "%20s", node->dump_type_name ());
-		fprintf (stderr, "%20s\n", node->dump_visibility ());
+			cnode->get_untransformed_body ();
+			debug_function (cnode->decl, 0);
 		}
-	}	
 }	
\ No newline at end of file
diff --git a/gcc/lto/lto-dump.h b/gcc/lto/lto-dump.h
index 352160c..3b6c9bc 100644
--- a/gcc/lto/lto-dump.h
+++ b/gcc/lto/lto-dump.h
@@ -29,4 +29,7 @@ void dump_list ();
 /*Dump specific variable or function used in IL.  */
 void dump_symbol ();
 
+/*Dump gimple body of specific function.  */
+void dump_body ();
+
 #endif
\ No newline at end of file
diff --git a/gcc/lto/lto.c b/gcc/lto/lto.c
index ab1eed3..88d1480 100644
--- a/gcc/lto/lto.c
+++ b/gcc/lto/lto.c
@@ -2170,7 +2170,7 @@ lto_file_read (lto_file *file, FILE *resolution_file, int *count)
   /* Finalize each lto file for each submodule in the merged object */
   for (file_data = file_list.first; file_data != NULL; file_data = file_data->next)
 lto_create_files_from_ids (file, file_data, count);
- 
+
   splay_tree_delete (file_ids);
   htab_delete (section_hash_table);
 
@@ -3373,6 +3373,10 @@ lto_main (void)
   if (flag_lto_dump_symbol)
 dump_symbol ();
 
+  /* Dump gimple body of specific function.  */
+  if (flag_lto_dump_body)
+dump_body ();
+
   timevar_stop (TV_PHASE_STREAM_IN);
 
   if (!seen_error ())
diff --git a/gcc/symtab.c b/gcc/symtab.c
index 1d2374f..0e08519 100644
--- a/gcc/symtab.c
+++ b/gcc/symtab.c
@@ -815,7 +815,7 @@ symtab_node::dump_visibility () const
 "default", "protected", "hidden", "internal"
   };
 
-  return visibility_types [DECL_VISIBILITY (decl)];
+  return visibility_types[DECL_VISIBILITY (decl)];
 }
 
 const char *
diff --git a/gcc/tree-cfg.h b/gcc/tree-cfg.h
index 73237a6..3e10d15 100644
--- a/gcc/tree-cfg.h
+++ b/gcc/tree-cfg.h
@@ -81,7 +81,7 @@ extern void fold_loop_internal_call (gimple *, tree);
 extern basic_block move_sese_region_to_fn (struct function 

Re: [GSOC] LTO dump tool project

[Martin Liška]

On 06/08/2018 03:40 PM, Martin Liška wrote:
> There's wrong declaration of the function in header file. I'll fix it soon
> on trunk. Please carry on with following patch:

Fixed in r261327.

Martin

Re: [GSOC] LTO dump tool project

[Martin Liška]

On 06/08/2018 03:27 PM, Hrishikesh Kulkarni wrote:
> Hi,
> 
> Linking is not taking place as the debug_function() being used is in
> tree-cfg.c. How should I go about on adding in make-file considering
> the dependencies?

Hi.

There's wrong declaration of the function in header file. I'll fix it soon
on trunk. Please carry on with following patch:

diff --git a/gcc/lto/lto.c b/gcc/lto/lto.c
index 17634797c6e..363b59febd6 100644
--- a/gcc/lto/lto.c
+++ b/gcc/lto/lto.c
@@ -55,6 +55,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "fold-const.h"
 #include "attribs.h"
 #include "builtins.h"
+#include "tree-cfg.h"
 
 
 /* Number of parallel tasks to run, -1 if we want to use GNU Make jobserver.  
*/
@@ -3338,6 +3339,8 @@ offload_handle_link_vars (void)
 void
 lto_main (void)
 {
+  // only test if it builds
+  debug_function (cfun->decl, TDF_NONE);
   /* LTO is called as a front end, even though it is not a front end.
  Because it is called as a front end, TV_PHASE_PARSING and
  TV_PARSE_GLOBAL are active, and we need to turn them off while
diff --git a/gcc/tree-cfg.h b/gcc/tree-cfg.h
index 73237a604be..9491bb45feb 100644
--- a/gcc/tree-cfg.h
+++ b/gcc/tree-cfg.h
@@ -81,7 +81,7 @@ extern void fold_loop_internal_call (gimple *, tree);
 extern basic_block move_sese_region_to_fn (struct function *, basic_block,
   basic_block, tree);
 extern void dump_function_to_file (tree, FILE *, dump_flags_t);
-extern void debug_function (tree, int) ;
+extern void debug_function (tree, dump_flags_t);
 extern void print_loops_bb (FILE *, basic_block, int, int);
 extern void print_loops (FILE *, int);
 extern void debug (struct loop );

Martin

> 
> Please find the diff file attached herewith.
> 
> Regards,
> Hrishikesh
> 
> On Tue, Jun 5, 2018 at 12:38 AM, Martin Liška  wrote:
>> On 06/04/2018 08:13 PM, Hrishikesh Kulkarni wrote:
>>>
>>> Hi,
>>>
>>> -fdump-lto-list will dump all the symbol list
>>
>>
>> I see extra new lines in the output:
>>
>> $ lto1 -fdump-lto-list main.o
>> [..snip..]
>> Symbol Table
>> NameTypeVisibility
>>
>>fwrite/15function default
>>
>>   foo/14function default
>>
>>  mystring/12variable default
>>
>>  pole/11variable default
>>
>>  main/13function default
>>
>>> -fdump-lto-list -demangle will dump all the list with symbol names
>>> demangled
>>
>>
>> Good for now. Note that non-demagle version prints function names with order
>> (/$number).
>> I would not print that.
>>
>>> -fdump-lto-symbol=foo will dump details of foo
>>
>>
>> I would really prefer to use symtab_node::debug for now. It presents all
>> details about
>> symbol instead of current implementation which does: '-fdump-lto-list | grep
>> foo'
>>
>>>
>>> The output(demangled) will be in tabular form like nm:
>>> Symbol Table
>>>  Name Type Visibility
>>>printffunction default
>>> kvariable default
>>>  mainfunction default
>>>   barfunction default
>>>   foofunction default
>>>
>>> I have tried to format the changes according to gnu coding style and
>>> added required methods in symtab_node.
>>
>>
>> That's nice that you came up with new symbol_node methods. It's much better.
>> About the GNU coding style, I still see trailing whitespace:
>>
>> === ERROR type #3: there should be no space before a left square bracket (1
>> error(s)) ===
>> gcc/symtab.c:818:26:  return visibility_types [DECL_VISIBILITY (decl)];
>>
>> === ERROR type #4: trailing whitespace (6 error(s)) ===
>> gcc/lto/lto-dump.c:40:4:void█
>> gcc/lto/lto-dump.c:45:0:█
>> gcc/lto/lto-dump.c:56:52:   fprintf (stderr,
>> "\n%20s",(flag_lto_dump_demangle)█
>> gcc/lto/lto-dump.c:73:53:   fprintf (stderr,
>> "\n%20s",(flag_lto_dump_demangle)█
>> gcc/lto/lto-dump.c:78:2:}█
>> gcc/lto/lto-dump.c:79:1:}█
>>
>> Martin
>>
>>
>>>
>>> Please find the diff file attached.
>>>
>>> Regards,
>>> Hrishikesh
>>>
>>> On Mon, Jun 4, 2018 at 2:06 PM, Martin Liška  wrote:

 On 06/01/2018 08:59 PM, Hrishikesh Kulkarni wrote:
>
> Hi,
> I have pushed the changes to github
> (https://github.com/hrisearch/gcc). Added a command line option for
> specific dumps of variables and functions used in IL e.g.
> -fdump-lto-list=foo will dump:
> Call Graph:
>
> foo/1 (foo)
>Type: function
>   visibility: default


 Hi.

 Thanks for the next step. I've got some comments about it:

 - -fdump-lto-list=foo is wrong option name, I would use -fdump-lto-symbol
or something similar.

 - 

Re: [GSOC] LTO dump tool project

[Hrishikesh Kulkarni]

Hi,

Linking is not taking place as the debug_function() being used is in
tree-cfg.c. How should I go about on adding in make-file considering
the dependencies?

Please find the diff file attached herewith.

Regards,
Hrishikesh

On Tue, Jun 5, 2018 at 12:38 AM, Martin Liška  wrote:
> On 06/04/2018 08:13 PM, Hrishikesh Kulkarni wrote:
>>
>> Hi,
>>
>> -fdump-lto-list will dump all the symbol list
>
>
> I see extra new lines in the output:
>
> $ lto1 -fdump-lto-list main.o
> [..snip..]
> Symbol Table
> NameTypeVisibility
>
>fwrite/15function default
>
>   foo/14function default
>
>  mystring/12variable default
>
>  pole/11variable default
>
>  main/13function default
>
>> -fdump-lto-list -demangle will dump all the list with symbol names
>> demangled
>
>
> Good for now. Note that non-demagle version prints function names with order
> (/$number).
> I would not print that.
>
>> -fdump-lto-symbol=foo will dump details of foo
>
>
> I would really prefer to use symtab_node::debug for now. It presents all
> details about
> symbol instead of current implementation which does: '-fdump-lto-list | grep
> foo'
>
>>
>> The output(demangled) will be in tabular form like nm:
>> Symbol Table
>>  Name Type Visibility
>>printffunction default
>> kvariable default
>>  mainfunction default
>>   barfunction default
>>   foofunction default
>>
>> I have tried to format the changes according to gnu coding style and
>> added required methods in symtab_node.
>
>
> That's nice that you came up with new symbol_node methods. It's much better.
> About the GNU coding style, I still see trailing whitespace:
>
> === ERROR type #3: there should be no space before a left square bracket (1
> error(s)) ===
> gcc/symtab.c:818:26:  return visibility_types [DECL_VISIBILITY (decl)];
>
> === ERROR type #4: trailing whitespace (6 error(s)) ===
> gcc/lto/lto-dump.c:40:4:void█
> gcc/lto/lto-dump.c:45:0:█
> gcc/lto/lto-dump.c:56:52:   fprintf (stderr,
> "\n%20s",(flag_lto_dump_demangle)█
> gcc/lto/lto-dump.c:73:53:   fprintf (stderr,
> "\n%20s",(flag_lto_dump_demangle)█
> gcc/lto/lto-dump.c:78:2:}█
> gcc/lto/lto-dump.c:79:1:}█
>
> Martin
>
>
>>
>> Please find the diff file attached.
>>
>> Regards,
>> Hrishikesh
>>
>> On Mon, Jun 4, 2018 at 2:06 PM, Martin Liška  wrote:
>>>
>>> On 06/01/2018 08:59 PM, Hrishikesh Kulkarni wrote:

 Hi,
 I have pushed the changes to github
 (https://github.com/hrisearch/gcc). Added a command line option for
 specific dumps of variables and functions used in IL e.g.
 -fdump-lto-list=foo will dump:
 Call Graph:

 foo/1 (foo)
Type: function
   visibility: default
>>>
>>>
>>> Hi.
>>>
>>> Thanks for the next step. I've got some comments about it:
>>>
>>> - -fdump-lto-list=foo is wrong option name, I would use -fdump-lto-symbol
>>>or something similar.
>>>
>>> - for -fdump-lto-list I would really prefer to use a format similar to
>>> nm:
>>>print a header with column description and then one line for a symbol
>>>
>>> - think about mangling/demangling of C++ symbols, you can take a look at
>>> nm it also has --demangle, --no-demangle
>>>
>>> - please learn & try to use an autoformat for your editor in order to
>>>fulfill GNU coding style. Following checker will help you:
>>>
>>> $ ./contrib/check_GNU_style.py /tmp/p
>>> === ERROR type #1: dot, space, space, end of comment (6 error(s)) ===
>>> gcc/lto/lto-dump.c:38:17:/*Dump everything*/
>>> gcc/lto/lto-dump.c:44:41:/*Dump variables and functions used in IL*/
>>> gcc/lto/lto-dump.c:73:50:/*Dump specific variables and functions used in
>>> IL*/
>>> gcc/lto/lto.c:3364:19:  /*Dump everything*/
>>> gcc/lto/lto.c:3368:43:  /*Dump variables and functions used in IL*/
>>> gcc/lto/lto.c:3372:52:  /*Dump specific variables and functions used in
>>> IL*/
>>>
>>> === ERROR type #2: lines should not exceed 80 characters (11 error(s))
>>> ===
>>> gcc/lto/lto-dump.c:51:80:static const char * const
>>> symtab_type_names[] = {"symbol", "function", "variable"};
>>> gcc/lto/lto-dump.c:56:80:fprintf (stderr, "\n%s (%s)",
>>> cnode->dump_asm_name (), cnode->name ());
>>> gcc/lto/lto-dump.c:57:80:fprintf (stderr, "\n  Type: %s",
>>> symtab_type_names[cnode->type]);
>>> gcc/lto/lto-dump.c:66:80:fprintf (stderr, "\n%s (%s)",
>>> vnode->dump_asm_name (), vnode->name ());
>>> gcc/lto/lto-dump.c:67:80:fprintf (stderr, "\n  Type: %s",
>>> symtab_type_names[vnode->type]);
>>> gcc/lto/lto-dump.c:80:80:   

Re: [GSOC] LTO dump tool project

[Martin Liška]

On 06/04/2018 08:13 PM, Hrishikesh Kulkarni wrote:

Hi,

-fdump-lto-list will dump all the symbol list


I see extra new lines in the output:

$ lto1 -fdump-lto-list main.o
[..snip..]
Symbol Table
NameTypeVisibility

   fwrite/15function default

  foo/14function default

 mystring/12variable default

 pole/11variable default

 main/13function default


-fdump-lto-list -demangle will dump all the list with symbol names demangled


Good for now. Note that non-demagle version prints function names with order 
(/$number).
I would not print that.


-fdump-lto-symbol=foo will dump details of foo


I would really prefer to use symtab_node::debug for now. It presents all 
details about
symbol instead of current implementation which does: '-fdump-lto-list | grep 
foo'



The output(demangled) will be in tabular form like nm:
Symbol Table
 Name Type Visibility
   printffunction default
kvariable default
 mainfunction default
  barfunction default
  foofunction default

I have tried to format the changes according to gnu coding style and
added required methods in symtab_node.


That's nice that you came up with new symbol_node methods. It's much better.
About the GNU coding style, I still see trailing whitespace:

=== ERROR type #3: there should be no space before a left square bracket (1 
error(s)) ===
gcc/symtab.c:818:26:  return visibility_types [DECL_VISIBILITY (decl)];

=== ERROR type #4: trailing whitespace (6 error(s)) ===
gcc/lto/lto-dump.c:40:4:void█
gcc/lto/lto-dump.c:45:0:█
gcc/lto/lto-dump.c:56:52:   fprintf (stderr, 
"\n%20s",(flag_lto_dump_demangle)█
gcc/lto/lto-dump.c:73:53:   fprintf (stderr, 
"\n%20s",(flag_lto_dump_demangle)█
gcc/lto/lto-dump.c:78:2:}█
gcc/lto/lto-dump.c:79:1:}█

Martin



Please find the diff file attached.

Regards,
Hrishikesh

On Mon, Jun 4, 2018 at 2:06 PM, Martin Liška  wrote:

On 06/01/2018 08:59 PM, Hrishikesh Kulkarni wrote:

Hi,
I have pushed the changes to github
(https://github.com/hrisearch/gcc). Added a command line option for
specific dumps of variables and functions used in IL e.g.
-fdump-lto-list=foo will dump:
Call Graph:

foo/1 (foo)
   Type: function
  visibility: default


Hi.

Thanks for the next step. I've got some comments about it:

- -fdump-lto-list=foo is wrong option name, I would use -fdump-lto-symbol
   or something similar.

- for -fdump-lto-list I would really prefer to use a format similar to nm:
   print a header with column description and then one line for a symbol

- think about mangling/demangling of C++ symbols, you can take a look at
nm it also has --demangle, --no-demangle

- please learn & try to use an autoformat for your editor in order to
   fulfill GNU coding style. Following checker will help you:

$ ./contrib/check_GNU_style.py /tmp/p
=== ERROR type #1: dot, space, space, end of comment (6 error(s)) ===
gcc/lto/lto-dump.c:38:17:/*Dump everything*/
gcc/lto/lto-dump.c:44:41:/*Dump variables and functions used in IL*/
gcc/lto/lto-dump.c:73:50:/*Dump specific variables and functions used in IL*/
gcc/lto/lto.c:3364:19:  /*Dump everything*/
gcc/lto/lto.c:3368:43:  /*Dump variables and functions used in IL*/
gcc/lto/lto.c:3372:52:  /*Dump specific variables and functions used in IL*/

=== ERROR type #2: lines should not exceed 80 characters (11 error(s)) ===
gcc/lto/lto-dump.c:51:80:static const char * const symtab_type_names[] = {"symbol", 
"function", "variable"};
gcc/lto/lto-dump.c:56:80:fprintf (stderr, "\n%s (%s)", 
cnode->dump_asm_name (), cnode->name ());
gcc/lto/lto-dump.c:57:80:fprintf (stderr, "\n  Type: %s", 
symtab_type_names[cnode->type]);
gcc/lto/lto-dump.c:66:80:fprintf (stderr, "\n%s (%s)", 
vnode->dump_asm_name (), vnode->name ());
gcc/lto/lto-dump.c:67:80:fprintf (stderr, "\n  Type: %s", 
symtab_type_names[vnode->type]);
gcc/lto/lto-dump.c:80:80:static const char * const symtab_type_names[] = {"symbol", 
"function", "variable"};
gcc/lto/lto-dump.c:87:80:fprintf (stderr, "\n%s (%s)", 
cnode->dump_asm_name (), cnode->name ());
gcc/lto/lto-dump.c:88:80:fprintf (stderr, "\n  Type: %s", 
symtab_type_names[cnode->type]);
gcc/lto/lto-dump.c:99:80:fprintf (stderr, "\n%s (%s)", 
vnode->dump_asm_name (), vnode->name ());
gcc/lto/lto-dump.c:100:80:fprintf (stderr, "\n  Type: %s", 
symtab_type_names[vnode->type]);
gcc/lto/Make-lang.in:25:80:LTO_OBJS = lto/lto-lang.o lto/lto.o lto/lto-object.o 

Re: [GSOC] LTO dump tool project

[Hrishikesh Kulkarni]

Hi,

-fdump-lto-list will dump all the symbol list
-fdump-lto-list -demangle will dump all the list with symbol names demangled
-fdump-lto-symbol=foo will dump details of foo

The output(demangled) will be in tabular form like nm:
Symbol Table
Name Type Visibility
  printffunction default
   kvariable default
mainfunction default
 barfunction default
 foofunction default

I have tried to format the changes according to gnu coding style and
added required methods in symtab_node.

Please find the diff file attached.

Regards,
Hrishikesh

On Mon, Jun 4, 2018 at 2:06 PM, Martin Liška  wrote:
> On 06/01/2018 08:59 PM, Hrishikesh Kulkarni wrote:
>> Hi,
>> I have pushed the changes to github
>> (https://github.com/hrisearch/gcc). Added a command line option for
>> specific dumps of variables and functions used in IL e.g.
>> -fdump-lto-list=foo will dump:
>> Call Graph:
>>
>> foo/1 (foo)
>>   Type: function
>>  visibility: default
>
> Hi.
>
> Thanks for the next step. I've got some comments about it:
>
> - -fdump-lto-list=foo is wrong option name, I would use -fdump-lto-symbol
>   or something similar.
>
> - for -fdump-lto-list I would really prefer to use a format similar to nm:
>   print a header with column description and then one line for a symbol
>
> - think about mangling/demangling of C++ symbols, you can take a look at
> nm it also has --demangle, --no-demangle
>
> - please learn & try to use an autoformat for your editor in order to
>   fulfill GNU coding style. Following checker will help you:
>
> $ ./contrib/check_GNU_style.py /tmp/p
> === ERROR type #1: dot, space, space, end of comment (6 error(s)) ===
> gcc/lto/lto-dump.c:38:17:/*Dump everything*/
> gcc/lto/lto-dump.c:44:41:/*Dump variables and functions used in IL*/
> gcc/lto/lto-dump.c:73:50:/*Dump specific variables and functions used in IL*/
> gcc/lto/lto.c:3364:19:  /*Dump everything*/
> gcc/lto/lto.c:3368:43:  /*Dump variables and functions used in IL*/
> gcc/lto/lto.c:3372:52:  /*Dump specific variables and functions used in IL*/
>
> === ERROR type #2: lines should not exceed 80 characters (11 error(s)) ===
> gcc/lto/lto-dump.c:51:80:static const char * const 
> symtab_type_names[] = {"symbol", "function", "variable"};
> gcc/lto/lto-dump.c:56:80:fprintf (stderr, "\n%s (%s)", 
> cnode->dump_asm_name (), cnode->name ());
> gcc/lto/lto-dump.c:57:80:fprintf (stderr, "\n  Type: %s", 
> symtab_type_names[cnode->type]);
> gcc/lto/lto-dump.c:66:80:fprintf (stderr, "\n%s (%s)", 
> vnode->dump_asm_name (), vnode->name ());
> gcc/lto/lto-dump.c:67:80:fprintf (stderr, "\n  Type: %s", 
> symtab_type_names[vnode->type]);
> gcc/lto/lto-dump.c:80:80:static const char * const 
> symtab_type_names[] = {"symbol", "function", "variable"};
> gcc/lto/lto-dump.c:87:80:fprintf (stderr, "\n%s 
> (%s)", cnode->dump_asm_name (), cnode->name ());
> gcc/lto/lto-dump.c:88:80:fprintf (stderr, "\n  Type: 
> %s", symtab_type_names[cnode->type]);
> gcc/lto/lto-dump.c:99:80:fprintf (stderr, "\n%s 
> (%s)", vnode->dump_asm_name (), vnode->name ());
> gcc/lto/lto-dump.c:100:80:fprintf (stderr, "\n  Type: 
> %s", symtab_type_names[vnode->type]);
> gcc/lto/Make-lang.in:25:80:LTO_OBJS = lto/lto-lang.o lto/lto.o 
> lto/lto-object.o attribs.o lto/lto-partition.o lto/lto-symtab.o lto/lto-dump.o
>
> === ERROR type #3: there should be exactly one space between function name 
> and parenthesis (15 error(s)) ===
> gcc/lto/lto-dump.c:39:9:void dump()
> gcc/lto/lto-dump.c:41:8:fprintf(stderr, "\nHello World!\n");
> gcc/lto/lto-dump.c:45:14:void dump_list()
> gcc/lto/lto-dump.c:74:15:void dump_list2()
> gcc/lto/lto-dump.c:85:13:   if (!strcmp(flag_lto_dump_list2, 
> cnode->name()))
> gcc/lto/lto-dump.c:97:16:   if (!strcmp(flag_lto_dump_list2, 
> vnode->name()))
> gcc/lto/lto-dump.h:23:9:void dump();
> gcc/lto/lto-dump.h:24:14:void dump_list();
> gcc/lto/lto-dump.h:25:15:void dump_list2();
> gcc/lto/lang.opt:67:7:LTO Var(flag_lto_dump)
> gcc/lto/lang.opt:71:7:LTO Var(flag_lto_dump_list)
> gcc/lto/lang.opt:75:36:LTO Driver RejectNegative Joined 
> Var(flag_lto_dump_list2)
> gcc/lto/lto.c:3366:8:dump();
> gcc/lto/lto.c:3370:13:dump_list();
> gcc/lto/lto.c:3374:14:dump_list2();
>
> === ERROR type #4: there should be no space before a left square bracket (4 
> error(s)) ===
> gcc/lto/lto-dump.c:59:19:   visibility_types [DECL_VISIBILITY 
> (cnode->decl)]);
> gcc/lto/lto-dump.c:69:19:   visibility_types [DECL_VISIBILITY 
> (vnode->decl)]);
> gcc/lto/lto-dump.c:90:20:   visibility_types 
> [DECL_VISIBILITY (cnode->decl)]);
> 

Re: [GSOC] LTO dump tool project

[Martin Liška]

On 06/01/2018 08:59 PM, Hrishikesh Kulkarni wrote:
> Hi,
> I have pushed the changes to github
> (https://github.com/hrisearch/gcc). Added a command line option for
> specific dumps of variables and functions used in IL e.g.
> -fdump-lto-list=foo will dump:
> Call Graph:
> 
> foo/1 (foo)
>   Type: function
>  visibility: default

Hi.

Thanks for the next step. I've got some comments about it:

- -fdump-lto-list=foo is wrong option name, I would use -fdump-lto-symbol
  or something similar.

- for -fdump-lto-list I would really prefer to use a format similar to nm:
  print a header with column description and then one line for a symbol

- think about mangling/demangling of C++ symbols, you can take a look at
nm it also has --demangle, --no-demangle

- please learn & try to use an autoformat for your editor in order to
  fulfill GNU coding style. Following checker will help you:

$ ./contrib/check_GNU_style.py /tmp/p
=== ERROR type #1: dot, space, space, end of comment (6 error(s)) ===
gcc/lto/lto-dump.c:38:17:/*Dump everything*/
gcc/lto/lto-dump.c:44:41:/*Dump variables and functions used in IL*/
gcc/lto/lto-dump.c:73:50:/*Dump specific variables and functions used in IL*/
gcc/lto/lto.c:3364:19:  /*Dump everything*/
gcc/lto/lto.c:3368:43:  /*Dump variables and functions used in IL*/
gcc/lto/lto.c:3372:52:  /*Dump specific variables and functions used in IL*/

=== ERROR type #2: lines should not exceed 80 characters (11 error(s)) ===
gcc/lto/lto-dump.c:51:80:static const char * const symtab_type_names[] 
= {"symbol", "function", "variable"};
gcc/lto/lto-dump.c:56:80:fprintf (stderr, "\n%s (%s)", 
cnode->dump_asm_name (), cnode->name ());
gcc/lto/lto-dump.c:57:80:fprintf (stderr, "\n  Type: %s", 
symtab_type_names[cnode->type]);
gcc/lto/lto-dump.c:66:80:fprintf (stderr, "\n%s (%s)", 
vnode->dump_asm_name (), vnode->name ());
gcc/lto/lto-dump.c:67:80:fprintf (stderr, "\n  Type: %s", 
symtab_type_names[vnode->type]);
gcc/lto/lto-dump.c:80:80:static const char * const symtab_type_names[] 
= {"symbol", "function", "variable"};
gcc/lto/lto-dump.c:87:80:fprintf (stderr, "\n%s (%s)", 
cnode->dump_asm_name (), cnode->name ());
gcc/lto/lto-dump.c:88:80:fprintf (stderr, "\n  Type: 
%s", symtab_type_names[cnode->type]);
gcc/lto/lto-dump.c:99:80:fprintf (stderr, "\n%s (%s)", 
vnode->dump_asm_name (), vnode->name ());
gcc/lto/lto-dump.c:100:80:fprintf (stderr, "\n  Type: 
%s", symtab_type_names[vnode->type]);
gcc/lto/Make-lang.in:25:80:LTO_OBJS = lto/lto-lang.o lto/lto.o lto/lto-object.o 
attribs.o lto/lto-partition.o lto/lto-symtab.o lto/lto-dump.o

=== ERROR type #3: there should be exactly one space between function name and 
parenthesis (15 error(s)) ===
gcc/lto/lto-dump.c:39:9:void dump()
gcc/lto/lto-dump.c:41:8:fprintf(stderr, "\nHello World!\n");
gcc/lto/lto-dump.c:45:14:void dump_list()
gcc/lto/lto-dump.c:74:15:void dump_list2()
gcc/lto/lto-dump.c:85:13:   if (!strcmp(flag_lto_dump_list2, 
cnode->name()))
gcc/lto/lto-dump.c:97:16:   if (!strcmp(flag_lto_dump_list2, vnode->name()))
gcc/lto/lto-dump.h:23:9:void dump();
gcc/lto/lto-dump.h:24:14:void dump_list();
gcc/lto/lto-dump.h:25:15:void dump_list2();
gcc/lto/lang.opt:67:7:LTO Var(flag_lto_dump)
gcc/lto/lang.opt:71:7:LTO Var(flag_lto_dump_list)
gcc/lto/lang.opt:75:36:LTO Driver RejectNegative Joined Var(flag_lto_dump_list2)
gcc/lto/lto.c:3366:8:dump();
gcc/lto/lto.c:3370:13:dump_list();
gcc/lto/lto.c:3374:14:dump_list2();

=== ERROR type #4: there should be no space before a left square bracket (4 
error(s)) ===
gcc/lto/lto-dump.c:59:19:   visibility_types [DECL_VISIBILITY 
(cnode->decl)]);
gcc/lto/lto-dump.c:69:19:   visibility_types [DECL_VISIBILITY 
(vnode->decl)]);
gcc/lto/lto-dump.c:90:20:   visibility_types 
[DECL_VISIBILITY (cnode->decl)]);
gcc/lto/lto-dump.c:102:20:  visibility_types 
[DECL_VISIBILITY (vnode->decl)]);

=== ERROR type #5: trailing whitespace (5 error(s)) ===
gcc/lto/lto-dump.c:50:0:█
gcc/lto/lto-dump.c:79:0:█
gcc/lto/lto-dump.c:92:2:}█
gcc/lto/lto-dump.c:98:3:{█
gcc/lto/lto-dump.c:105:1:}█

And please try to avoid adding blank lines / remove blank lines in files which 
you don't modify.
Examples: cgraph.c, varpool.c. Note that the checker is not 100% sure, but will 
help you.

> 
> Regards,
> Hrishikesh
> 
> On Tue, May 29, 2018 at 11:13 PM, Martin Liška  wrote:
>> On 05/29/2018 07:38 PM, Martin Liška wrote:
>>> $ nm main.o
>>>  T main
>>>  T mystring
>>>  C pole
>>
>> Or we can be inspired by readelf:
>>
>> $ readelf -s a.out
>> [snip]
>> Symbol table '.symtab' contains 74 entries:
>>Num:Value  Size TypeBind   Vis  Ndx Name
>> 66: 00601250 0 NOTYPE  GLOBAL DEFAULT   24 _end
>> 

Re: [GSOC] LTO dump tool project

[Hrishikesh Kulkarni]

Hi,
I have pushed the changes to github
(https://github.com/hrisearch/gcc). Added a command line option for
specific dumps of variables and functions used in IL e.g.
-fdump-lto-list=foo will dump:
Call Graph:

foo/1 (foo)
  Type: function
 visibility: default

Regards,
Hrishikesh

On Tue, May 29, 2018 at 11:13 PM, Martin Liška  wrote:
> On 05/29/2018 07:38 PM, Martin Liška wrote:
>>
>> $ nm main.o
>>  T main
>>  T mystring
>>  C pole
>
>
> Or we can be inspired by readelf:
>
> $ readelf -s a.out
> [snip]
> Symbol table '.symtab' contains 74 entries:
>Num:Value  Size TypeBind   Vis  Ndx Name
> 66: 00601250 0 NOTYPE  GLOBAL DEFAULT   24 _end
> 67: 004004b043 FUNCGLOBAL DEFAULT   13 _start
> 68: 00601038 0 NOTYPE  GLOBAL DEFAULT   24 __bss_start
> 69: 0040058270 FUNCGLOBAL DEFAULT   13 main
> 70:  0 FUNCGLOBAL DEFAULT  UND
> fwrite@@GLIBC_2.2.5
>
> Martin
diff --git a/gcc/cgraph.c b/gcc/cgraph.c
index 9a7d54d..b868695 100644
--- a/gcc/cgraph.c
+++ b/gcc/cgraph.c
@@ -2234,6 +2234,7 @@ cgraph_node::dump (FILE *f)
 fprintf (f, "  Is instrumented version.\n");
   else if (instrumented_version)
 fprintf (f, "  Has instrumented version.\n");
+
 }
 
 /* Dump call graph node NODE to stderr.  */
diff --git a/gcc/lto/Make-lang.in b/gcc/lto/Make-lang.in
index 4695077..465662e 100644
--- a/gcc/lto/Make-lang.in
+++ b/gcc/lto/Make-lang.in
@@ -22,7 +22,7 @@
 # The name of the LTO compiler.
 LTO_EXE = lto1$(exeext)
 # The LTO-specific object files inclued in $(LTO_EXE).
-LTO_OBJS = lto/lto-lang.o lto/lto.o lto/lto-object.o attribs.o lto/lto-partition.o lto/lto-symtab.o
+LTO_OBJS = lto/lto-lang.o lto/lto.o lto/lto-object.o attribs.o lto/lto-partition.o lto/lto-symtab.o lto/lto-dump.o
 lto_OBJS = $(LTO_OBJS)
 
 # this is only useful in a LTO bootstrap, but this does not work right
diff --git a/gcc/lto/lang.opt b/gcc/lto/lang.opt
index 0a408d3..7600840 100644
--- a/gcc/lto/lang.opt
+++ b/gcc/lto/lang.opt
@@ -63,6 +63,18 @@ fwpa=
 LTO Driver RejectNegative Joined Var(flag_wpa)
 Whole program analysis (WPA) mode with number of parallel jobs specified.
 
+fdump
+LTO Var(flag_lto_dump)
+Call the dump function.
+
+fdump-lto-list
+LTO Var(flag_lto_dump_list)
+Call the dump function for variables and function in IL.
+
+fdump-lto-list=
+LTO Driver RejectNegative Joined Var(flag_lto_dump_list2)
+
+
 fresolution=
 LTO Joined
 The resolution file.
diff --git a/gcc/lto/lto-dump.c b/gcc/lto/lto-dump.c
new file mode 100644
index 000..90976cb
--- /dev/null
+++ b/gcc/lto/lto-dump.c
@@ -0,0 +1,105 @@
+/* LTO dump tool
+   Copyright (C) 2009-2018 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify it under
+the terms of the GNU General Public License as published by the Free
+Software Foundation; either version 3, or (at your option) any later
+version.
+
+GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+WARRANTY; without even the implied warranty of MERCHANTABILITY or
+FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3.  If not see
+.  */
+
+#include "config.h"
+#include "system.h"
+#include "coretypes.h"
+#include "target.h"
+#include "function.h"
+#include "basic-block.h"
+#include "tree.h"
+#include "gimple.h"
+#include "cgraph.h"
+#include "lto-streamer.h"
+#include "ipa-utils.h"
+#include "builtins.h"
+#include "alias.h"
+#include "lto-symtab.h"
+#include "stringpool.h"
+#include "attribs.h"
+#include "stdio.h"
+
+/*Dump everything*/
+void dump()
+{
+	fprintf(stderr, "\nHello World!\n");
+}
+
+/*Dump variables and functions used in IL*/
+void dump_list()
+{
+
+	fprintf (stderr, "Call Graph:\n");
+	cgraph_node *cnode;
+	
+	static const char * const symtab_type_names[] = {"symbol", "function", "variable"};
+  	static const char * const visibility_types[] = {
+"default", "protected", "hidden", "internal" };
+	FOR_EACH_FUNCTION (cnode)
+	{
+		fprintf (stderr, "\n%s (%s)", cnode->dump_asm_name (), cnode->name ());
+		fprintf (stderr, "\n  Type: %s", symtab_type_names[cnode->type]);
+		fprintf (stderr, "\n visibility: %s\n",
+		visibility_types [DECL_VISIBILITY (cnode->decl)]);
+	}
+
+	fprintf (stderr, "\nVarpool:\n");
+	varpool_node *vnode;
+FOR_EACH_VARIABLE (vnode)
+{
+		fprintf (stderr, "\n%s (%s)", vnode->dump_asm_name (), vnode->name ());
+		fprintf (stderr, "\n  Type: %s", symtab_type_names[vnode->type]);
+		fprintf (stderr, "\n visibility:%s\n",
+		visibility_types [DECL_VISIBILITY (vnode->decl)]);
+	}
+}
+
+/*Dump specific variables and functions used in IL*/
+void dump_list2()
+{
+
+	fprintf (stderr, "Call Graph:\n");
+	cgraph_node *cnode;
+	
+	static const char * const symtab_type_names[] = 

Re: [GSOC] LTO dump tool project

[Martin Liška]

On 05/29/2018 07:38 PM, Martin Liška wrote:

$ nm main.o
 T main
 T mystring
 C pole


Or we can be inspired by readelf:

$ readelf -s a.out
[snip]
Symbol table '.symtab' contains 74 entries:
   Num:Value  Size TypeBind   Vis  Ndx Name
66: 00601250 0 NOTYPE  GLOBAL DEFAULT   24 _end
67: 004004b043 FUNCGLOBAL DEFAULT   13 _start
68: 00601038 0 NOTYPE  GLOBAL DEFAULT   24 __bss_start
69: 0040058270 FUNCGLOBAL DEFAULT   13 main
70:  0 FUNCGLOBAL DEFAULT  UND fwrite@@GLIBC_2.2.5

Martin

Re: [GSOC] LTO dump tool project

[Martin Liška]

On 05/29/2018 07:17 PM, Prathamesh Kulkarni wrote:

Shouldn't fdump-lto-list be enabled only if fdump is enabled  ?


The option is dummy, and eventually all do options will be moved
to a separate tool called lto-dump. Thus all the prefixed '-fdump-lto-foo'
will be replaced with -foo is guess.

Martin

Re: [GSOC] LTO dump tool project

[Martin Liška]

On 05/29/2018 07:03 PM, Hrishikesh Kulkarni wrote:

Hi,

My exams have finally ended and I have started working on the GSOC project.
I have forked GCC mirror (https://github.com/hrisearch/gcc) and
created a option for dumping functions and variables used in IL.
Please find the patch attached herewith.


Hello.

Good start. You branched the repository but your forget to push the commit
you sent as attachment. Second issues is that the patch is not against
GCC trunk, but against your local branch. Thus one can't apply that.

About the options:
- once you send a new functionality, it's fine to paste a sample output
- for now I would remove the dummy flag_lto_dump flag
- I would expect for -fdump-lto-list something like what nm does:

$ nm main.o
 T main
 T mystring
 C pole

Then of course you can add some level of verbosity which can print what you 
have.
Would be also handy during the time to come up with some sorting, but it can 
wait.

That said, the direction is fine. Please carry on.

Thanks,
Martin



Regards,
Hrishikesh

Re: [GSOC] LTO dump tool project

[Prathamesh Kulkarni]

On 29 May 2018 at 22:33, Hrishikesh Kulkarni  wrote:
> Hi,
>
> My exams have finally ended and I have started working on the GSOC project.
> I have forked GCC mirror (https://github.com/hrisearch/gcc) and
> created a option for dumping functions and variables used in IL.
> Please find the patch attached herewith.
diff --git a/gcc/lto/lang.opt b/gcc/lto/lang.opt
index 1083f9b..ae66c06 100644
--- a/gcc/lto/lang.opt
+++ b/gcc/lto/lang.opt
@@ -66,7 +66,11 @@ Whole program analysis (WPA) mode with number of
parallel jobs specified.

 fdump
 LTO Var(flag_lto_dump)
-Call the dump function
+Call the dump function.
+
+fdump-lto-list
+LTO Var(flag_lto_dump_list)
+Call the dump function for variables and function in IL.

Instead of making separate options -fdump and -fdump-lto-list,
would it be a good idea to make it a "sub option" to -fdump like
lto1 -fdump,-l which would list all symbols within the LTO object file ?

 fresolution=
 LTO Joined
diff --git a/gcc/lto/lto-dump.c b/gcc/lto/lto-dump.c
index b6a8b45..5e4d069 100644
--- a/gcc/lto/lto-dump.c
+++ b/gcc/lto/lto-dump.c
@@ -38,4 +38,21 @@ along with GCC; see the file COPYING3.  If not see
 void dump()
 {
  fprintf(stderr, "\nHello World!\n");
+}
+
+void dump_list()
+{
+
+ fprintf (stderr, "Call Graph:\n\n");
+ cgraph_node *cnode;
+ FOR_EACH_FUNCTION (cnode)
+cnode->dump (stderr);
+fprintf(stderr, "\n\n" );
+
+ fprintf (stderr, "Varpool:\n\n");
+ varpool_node *vnode;
+FOR_EACH_VARIABLE (vnode)
+ vnode->dump (stderr);
+fprintf(stderr, "\n\n" );
+
 }
\ No newline at end of file
Formatting nit - Add comments for the newly added functions.

diff --git a/gcc/lto/lto-dump.h b/gcc/lto/lto-dump.h
index 4a06217..5ee71c6 100644
--- a/gcc/lto/lto-dump.h
+++ b/gcc/lto/lto-dump.h
@@ -21,5 +21,6 @@ along with GCC; see the file COPYING3.  If not see
 #define GCC_LTO_DUMP_H_

 void dump();
+void dump_list();

 #endif
\ No newline at end of file
diff --git a/gcc/lto/lto.c b/gcc/lto/lto.c
index 9c79242..93ef52b 100644
--- a/gcc/lto/lto.c
+++ b/gcc/lto/lto.c
@@ -3360,6 +3360,11 @@ lto_main (void)
 dump();
   }

+  if (flag_lto_dump_list)
+  {
+dump_list();
+  }
+
Formatting nit - Avoid braces for single statement within if.
Shouldn't fdump-lto-list be enabled only if fdump is enabled  ?

Thanks,
Prathamesh

   timevar_stop (TV_PHASE_STREAM_IN);

   if (!seen_error ())
>
> Regards,
> Hrishikesh