On Fri, Jun 5, 2009 at 12:05 PM, Alexandre Oliva <aol...@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.
