Re: VTA merge?

[Alexandre Oliva <aoliva at redhat dot com>]

On Jun  5, 2009, Richard Guenther <richard.guenther@gmail.com> wrote:

> So if I understand the above right then VTA is a new source of
> code-generation differences with -g vs. -g0.

It was, but that was before I spent several months stopping it from
being it ;-)

And once VTA is on and bootstrap-debug is the rule rather than the
exception (with RTH's suggestion, it will again be faster than normal
bootstrap, and catch even some regressions that current
BUILD_CONFIG=bootstrap-debug doesn't), it won't be just me catching and
fixing these ;-)

FTR, in the last two or three merges, I've had more -fcompare-debug
regressions with VTA disabled than with it enabled.  Perhaps we should
default to BUILD_CONFIG=bootstrap-debug?  It would be a start, but it
wouldn't have caught all of the recent regressions.  Some of them only
affected C++ and Ada testcases, and bootstrap-debug won't catch these.
It takes -fcompare-debug for the testsuite run or something equivalent
to do so.

Hopefully people who run automated testers can be talked into using the
-fcompare-debug option for the library builds and testsuite runs.

> IMHO a much more convincing way to avoid code generation
> differences with -g vs. -g0 and VTA would be to _always_ have
> the debug statements/instructions around, regardless of -g/-g0

That's an option I haven't discarded, but I wouldn't be able to claim
VTA had zero cost when disabled if that was so.

It might make sense to have an option that emitted all notes but just
discarded them at the end, rather than actually emitting location notes
out of them.  Although I'm not sure how useful it would be: as long as
you can still get debug info without VTA (and you can), you can get the
same effect of such an option:

-fno-var-tracking-assignments, with -g0 or -g, will get you the same
debug info we emit it nowadays

-fvar-tracking-assignments followed by strip will get you the same
object code you'd have gotten with the approach you suggest

Since stripping is trivial, and probably the most common use, the most
interesting case is probably the one in which you start out from a
binary that fails and then find out the failure can't be duplicated once
you build with VTA.  Building with -fcompare-debug will let you know
you're running into one of these cases, and then you can resort to
disabling VTA and trying to make do with the sucky debug info we emit
today.

> This would also ensure we keep a very good eye on
> compile-time/memory-usage overhead of the debug instructions.

We can probably think of better ways to waste memory and compile time
;-)

Not that keeping them on check isn't something we should all strive to
do, mind you.

> As of the var-tracking changes - do they make sense even with
> the current state of affairs?

Most of it would just fit in, but it would obviously have to be
retargeted to take the input of known bindings from something else.

> I remember us enhancing var-tracking for the var-mappings approach as
> well.

Yeah, it should be pretty easy to retarget VTA to take, instead of debug
insns, any other source of information that correlates user variables
with locations at points in which they are known at first, and all the
machinery should propagate that information and figure out the rest:
equivalences, confluences, etc.

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