This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: VTA merge - introduction


On Fri, Jun 5, 2009 at 12:12 PM, Alexandre Oliva<aoliva@redhat.com> wrote:
> I'm going to post the 11 patches that will bring VTA support into the
> trunk in reply to this e-mail, adjusting the subject to the patch name
> listed below, along with the descriptions, copied from the e-mail I just
> posted to gcc@.
>
> cmdline (7K) - new command line flags to turn VTA on or off, as well as
> a few debugging options that helped me debug it
>
> ssa (55K) - introduce debug bind stmts in the tree and tuples level
>
> ssa-to-rtl (24K) - convert debug bind stmts to debug insns
>
> rtl (48K) - introduce debug insns in the RTL level
>
> tracking (176K) - turn debug insns into var_location notes
>
> ssa-compare-debug (22K) - fix -fcompare-debug errors that showed up in
> the presence of debug bind stmts
>
> rtl-compare-debug (53K) - fix -fcompare-debug errors that showed up in the
> presence of debug insns
>
> sched (63K) - fix schedulers (except for sel-sched, that's only partially
> fixed, which means VTA is not ready for -O3 on IA64) to deal properly
> with debug insns
>
> ports (9K) - minor adjustments to ports, mostly to schedulers, to
> avoid -fcompare-debug regressions
>
> testsuite-guality (16K) - (still small) debug info quality testsuite
>
> buildopts (4K) - new BUILD_CONFIG options that can test VTA more thoroughly

So I have played a bit with the branch.  My favorite testcase (tramp3d)
grows 1% in debug-info size.  That sounds both promising and not ;)
In fact the only difference I can see when debugging around is that
VTA prints <value optimized out> for all scalars while with current trunk
I simply have 'No symbol "foo" in current context'.

Looking at the IL at the end of tree compilation I still see that more than
50% of all instructions are of DEBUG kind.  And there are lots of
redundancies like

  # DEBUG indexD.160664 => 0
  # DEBUG cD.160665 => 0
  # DEBUG cD.160665 => 0
  # DEBUG indexD.160664 => 0

that seem to get cleaned up only in var-tracking.  DEBUG insns also
seem to keep unused local variables available until var-tracking as
can be seen with the following testcase:

struct X { int a[128]; };
int
main()
{
  struct X x;
  struct X *p = &x;
  return 0;
}

IMHO a cleanup pass is needed here, which can also serve as a way
to fixup SSA form by either removing/NULLing DEBUG stmts that
have uses that are not dominated by their definitions or accordingly
move the DEBUG stmts if there are no intermediate DEBUG stmts
clobbering the tracked variable.

What kind of applications did you test/debug to get a feeling for the
quality of debug information with optimization turned on?  What is
the typical size impact on debug information with VTA turned on?

Thanks,
Richard.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]