Re: VTA merge?

[Richard Guenther <richard dot guenther at gmail dot com>]

On Fri, Jun 5, 2009 at 12:05 PM, Alexandre Oliva <aoliva@redhat.com> wrote:
> It's been a very long time since I started working in the
> var-tracking-assignments branch. ?It is finally approaching a state in
> which I'm comfortable enough to propose that it be integrated.
>
> Alas, it's not quite finished yet and, unless it is merged, it might
> very well never be. ?New differences in final RTL between -g and -g0
> keep popping up: I just found out one more that went in as recently as
> last week (lots of -O3 -g torture testsuite failures in -fcompare-debug
> test runs). ?After every merge, I spent an inordinate amount of time
> addressing such -fcompare-debug regressions.
>
> I'm not complaining. ?I actually enjoy doing that, it is fun. ?But it
> never ends, and it took time away from implementing the features that,
> for a long time, were missing. ?I think it's close enough to ready now
> that I feel it is no longer unfair to request others to share the burden
> of keeping GCC from emitting different code when given -g compared with
> -g0, a property we should have always ensured.
>
>
> == What is VTA?
>
> This project aims at getting GCC to emit debug information for local
> variables that is always correct, and as complete as possible. ?By
> correct, I mean, if GCC says a variable is at a certain location at a
> certain point in the program, that location must hold the value of the
> variable at that point. ?By complete, I mean if the value of the
> variable is available somewhere, or can be computed from values
> available somewhere, then debug information for the variable should tell
> the debug information consumer how to obtain or compute it.
>
> The key to keep the mapping between SL (source-level) variables and IR
> objects from being corrupted or lost was to introduce explicit IR
> mappings that, on the SL hand, remained stable fixed points and, on the
> IR hand, expressions that got naturally adjusted as part of the
> optimization process, without any changes to the optimization passes.
>
> Alas, no changes to the passes would be too good to be true. ?It was
> indeed true for several of them, but many that dealt with special
> boundary cases such as single or no occurrences of references to a
> value, or that counted references to make decisions, had to be taught
> how to disregard references that appeared in these new binding IR
> elements. ?Others had to be taught to disregard these elements when
> checking for the absence of intervening code between a pair of
> statements or instructions.
>
> In nearly all cases, the changes were trivial, and the need for them was
> shown in -fcompare-debug or bootstrap-debug testing.

So if I understand the above right then VTA is a new source of
code-generation differences with -g vs. -g0.  A possibly quite
bad one (compared to what we have now).

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
or -fvta or -fno-vta (that would merely switch var-tracking into
the new mode).  This would also ensure we keep a very good
eye on compile-time/memory-usage overhead of the debug
instructions.

As of the var-tracking changes - do they make sense even with
the current state of affairs?  I remember us enhancing var-tracking
for the var-mappings approach as well.

Richard.