On Jun 5, 2009, Richard Guenther <richard.guent...@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