On Thu, 2018-07-05 at 13:04 -0600, Jeff Law wrote:
> On 07/05/2018 09:27 AM, Qing Zhao wrote:
> >
> > > On Jul 3, 2018, at 7:19 PM, Jeff Law <l...@redhat.com
> > > <mailto:l...@redhat.com>> wrote:
> > >
> > > On 07/03/2018 12:28 PM, Qing Zhao wrote:
> > > >
> > > > > >
> > > > > > >
> > > > > > > In order to collect complete information on all the
> > > > > > > inlining
> > > > > > > transformation that GCC applies on a given program,
> > > > > > > I searched online, and found that the option -fopt-info-
> > > > > > > inline
> > > > > > > might be
> > > > > > > the right option to use:
> > > > > > >
> > > > > > > in which, it mentioned:
> > > > > > >
> > > > > > > "As another example,
> > > > > > > gcc -O3 -fopt-info-inline-optimized-missed=inline.txt
> > > > > > > outputs information about missed optimizations as well as
> > > > > > > optimized
> > > > > > > locations from all the inlining passes into inline.txt.
> > > > > > >
> > > > > > > “
> > > > > > >
> > > > > > > Then I checked a very small testcase with GCC9 as
> > > > > > > following:
> > > > > > >
> > > > > > > [qinzhao@localhost inline_report]$ cat inline_1.c
> > > > > > > static int foo (int a)
> > > > > > > {
> > > > > > > return a + 10;
> > > > > > > }
> > > > > > >
> > > > > > > static int bar (int b)
> > > > > > > {
> > > > > > > return b - 20;
> > > > > > > }
> > > > > > >
> > > > > > > static int boo (int a, int b)
> > > > > > > {
> > > > > > > return foo (a) + bar (b);
> > > > > > > }
> > > > > > >
> > > > > > > extern int v_a, v_b;
> > > > > > > extern int result;
> > > > > > >
> > > > > > > int compute ()
> > > > > > > {
> > > > > > > result = boo (v_a, v_b);
> > > > > > > return result;
> > > > > > > }
> > > > > > >
> > > > > > > [qinzhao@localhost inline_report]$
> > > > > > > /home/qinzhao/Install/latest/bin/gcc
> > > > > > > -O3 -fopt-info-inline-optimized-missed=inline.txt
> > > > > > > inline_1.c -S
> > > > > > > [qinzhao@localhost inline_report]$ ls -l inline.txt
> > > > > > > -rw-rw-r--. 1 qinzhao qinzhao 0 Jul 3 11:25 inline.txt
> > > > > > > [qinzhao@localhost inline_report]$ cat inline_1.s
> > > > > > > .file"inline_1.c"
> > > > > > > .text
> > > > > > > .p2align 4,,15
> > > > > > > .globlcompute
> > > > > > > .typecompute, @function
> > > > > > > compute:
> > > > > > > .LFB3:
> > > > > > > .cfi_startproc
> > > > > > > movlv_a(%rip), %edx
> > > > > > > movlv_b(%rip), %eax
> > > > > > > leal-10(%rdx,%rax), %eax
> > > > > > > movl%eax, result(%rip)
> > > > > > > ret
> > > > > > > .cfi_endproc
> > > > > > > .LFE3:
> > > > > > > .sizecompute, .-compute
> > > > > > > .ident"GCC: (GNU) 9.0.0 20180702 (experimental)"
> > > > > > > .section.note.GNU-stack,"",@progbits
> > > > > > >
> > > > > > > From the above, we can see:
> > > > > > > 1. the call chains to —>“boo”->”foo”, “bar” in the
> > > > > > > routine “compute”
> > > > > > > are completely inlined into “compute”;
> > > > > > > 2. However, there is NO any inline information is dumped
> > > > > > > into
> > > > > > > “inline.txt”.
> > > > > > >
> > > > > > >
> > > > > > > So, My questions are:
> > > > > > >
> > > > > > > 1. Is the option -fopt-info-inline the right option to
> > > > > > > use to get the
> > > > > > > complete inlining transformation info from GCC?
> > > > > > > 2. is this a bug that the current -fopt-info-inline
> > > > > > > cannot dump
> > > > > > > anything for this testing case?
> > > > > >
> > > > > > I think the early inliner doesn't use opt-info yet.
> > > > >
> > > > > so, shall we add the opt-info support to early inliner?
> > > >
> > > > I just created the following PR to record this work:
> > > >
> > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86395
> > > > let me know if I missed anything.
> > >
> > > I'm hoping that the work David is doing WRT optimization
> > > information
> > > will be usable for the inliner as well.
> >
> > where can I find more details of David’s work?
>
> I don't have pointers to all the discussion handy. BUt here's one of
> the early messages:
>
> https://gcc.gnu.org/ml/gcc-patches/2018-05/msg01675.html
I'm currently attacking the problem of "better optimization
information" from two directions:
(a) More destinations for the existing optimization reports: being able
to send them through the diagnostics subsystem, and to be able to save
them in a machine-readable format from which reports can be generated
(e.g. prioritized by code hotness). The initial patch kit Jeff linked
to above introduced a new API for doing that, but I'm no longer doing
that, instead working on using the existing "dump_*" API in dumpfile.h.
Some of this work is now in trunk: dump messages are now tagged with
metadata about the hotness of the code being optimized, and where in
GCC's own code the messages was emitted from ...but this new metadata
is being dropped on the floor in dumpfile.c right now. The latest
version of the patch kit for (a) is awaiting review at:
"[PATCH 0/2] v4: optinfo framework and remarks"
https://gcc.gnu.org/ml/gcc-patches/2018-07/msg00066.html
(b) I'm looking at new, improved optimization reports for
vectorization, by capturing higher-level information about why a loop
can't be vectorized, in a form that hopefully is useful to an end-user.
See a (very rough) prototype here:
* "[PATCH] [RFC] Higher-level reporting of vectorization problems"
* https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01462.html
I'm working on a less rough version of (b) and hope to post it to gcc-
patches soon.
Hope this sounds sane
Dave
