Re: VTA merge - introduction

[Alexandre Oliva <aoliva at redhat dot com>]

On Jun  9, 2009, Ian Lance Taylor <iant@google.com> wrote:

> Improvements in correctness of the form "this variable is optimized out"
> rather than printing garbage values are worth something, but they aren't
> worth very much.

Agreed.

> It's not clear to me that the VTA patch is worth it if
> that is the main improvement that we get.

We certainly get a lot more as it stands now.  Just comparing the test
results of the few trivial guality tests is quite revealing.  Current
GCC sucks rocks at them, while VTA manages to get a bunch of perfect
scores at -O2.  Where it doesn't, on x86_64, it's because we (still)
can't distinguish âmodified right after callâ from âmodified during the
callâ in var-tracking.  At other optimization levels, and on x86_32, the
lack for stack slot merging in dataflow confluences in var-tracking,
that I'm supposed to be working on and finish in a few days, is the
primary cause.

> I know that we get more than that, but how much more?

Without debug info extensions, a lot.  With extensions to support
constants and computed expressions (standard in Dwarf4 AFAICT), even
more.  With additional cleverness in combining expressions across basic
blocks, maybe even more, but that's where diminishing returns may become
an issue.

> for this patch I would like to see significant improvements in debug
> information before we commit to it, not after.

You got it on x86_64 already.  You'll get it on the register-starved
(and therefore stack slot-heavy) x86_32 too soon.

> If things don't work out, it's relatively easy for us to rip out every
> conditional on DEBUG_INSN_P.  We can find them with grep and what to do
> is obvious.  Ripping out other changes may be more difficult.  Obviously
> we don't want to rip anything out, but I want to strike a balance
> between being careful about the potential but perhaps unproven future
> benefits of VTA and making your life easier during development.

Thanks.  Grepping for DEBUG_INSN_P alone won't do, but if you add
MAY_HAVE_DEBUG_(INSN|STMT)S, IS_DEBUG_STMT, IS_DEBUG_BIND (changed per
richi's request to is_gimple_debug and gimple_debug_bind_p in my local
tree), you should get something that approaches full coverage, except
for var-tracking itself.

Should I add VTA marker comments to other changes that wouldn't get any
of the grep hits above?

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