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 Jun  5, 2009, Richard Guenther <> wrote:

> 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

Are the locations (line numbers) of these statements different?  If they
are, it's different statements we're talking about, and there's this
thought of representing it so that you could step through side effects
that didn't generate code, in much the same way that GDB enables you
today to step into or out of an inlined function without changing the

Anyhow, I'm certainly willing to look into running the existing
duplicate-removal code more often, if it would help.  Smallish testcases
that demonstrate the problem would be welcome, although I'm sure I
wouldn't have much trouble coming up with some of my own ;-)

> DEBUG insns also seem to keep unused local variables available until
> var-tracking as can be seen with the following testcase:

available in what sense?  If this kept the variable available as in it
got a stack slot, this would have been flagged by -fcompare-debug, so
you must be speaking of something else.  I can't tell what it is.

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

We do exactly this check_and_update_debug_stmt(), except for removal of
redundant debug stmts.  I'm pretty sure I implemented some such removal
at some point, but I don't even remember whether it was in gimple,
expand or rtl :-(

> What kind of applications did you test/debug to get a feeling for the
> quality of debug information with optimization turned on?

Pretty much only GCC itself so far.  I've constantly debugged its stage3
optimized at -O1, -O2 and -O3, even before fixing the brown paper bag
bug that I started fixing early this year and completed the fix and the
fallout and the missing features and the order-of-magnitude speedups to
make it work reasonably about month ago.

I can't say I was always happy with the debug info it produced.  Every
time I looked, the shortcomings had to do with either the very problem I
was working on, or the other bits that are still missing, detailed

> What is the typical size impact on debug information with VTA turned
> on?

I can get back to you with an answer, if you want, but I can tell you
that the answer may still be quite misleading at this point.

We still don't merge memory (stack) locations properly at confluence
points, so we lose debug information, reducing location lists, perhaps
making them even smaller that you'd get with the current debug info
generator.  More correct, but less complete.  Implementing this is my
next priority.

Furthermore, we still don't emit locations for computed or constant
values, because there's no way to represent them in Dwarf-3.  Once we do
(Dwarf-4 seems to have standardized a way to do this), merging
expressions at confluence points will enable even more locations to be
output into debug info.

Alexandre Oliva, freedom fighter
You must be the change you wish to see in the world. -- Gandhi
Be Free! --   FSF Latin America board member
Free Software Evangelist      Red Hat Brazil Compiler Engineer

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