This is the mail archive of the 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 6:42 PM, Richard
Guenther<> wrote:
> On Fri, Jun 5, 2009 at 12:12 PM, Alexandre Oliva<> 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?


struct X { int a[128]; } x;
  int i;
  for (i=0; i<3; ++i)
    x.a[i] = i;
  return 0;

I see we have debug insns properly but still i is printed as optimized out.
Probably because var-tracking doesn't handle constants as location?


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