Re: Designs for better debug info in GCC (was: Re: [vta] don't let debug insns get in the way of simple vect reduction)

[Ian Lance Taylor <iant at google dot com>]

Alexandre Oliva <aoliva@redhat.com> writes:

> I've pondered both alternatives, and decided that the latter was the
> only testable path.  If we had a reliable debug information tester, we
> could proceed incrementally with the first alternative; it might be
> viable, but I don't really see that it would make things any simpler.

It seems to me that this is a reason to write a reliable debug
information tester.  Your approach gives you a point solution--did
anything change today--but it doesn't give us a maintenance
solution--did anything change over time?


> Since one of the requirements I was given was that debug information
> be correct (as in, if I don't know where a variable is, debug
> information must say so, rather than say the variable is somewhere it
> really isn't), going without additional annotations just wouldn't
> work.  Therefore, I figured I'd have to bite the bullet and take the
> longer path, even though I don't dispute that it is possible to
> achieve many improvements with the simpler approach.

While I understand that you were given certain requirements, for the
purposes of mainline gcc we need to weigh costs and benefits.  How
many of our users are looking for precise debugging of optimized code,
and how much are they willing to pay for that?  Will our users overall
be better served by the 90% solution?


> 1. every single gimple assignment grows by one word, to hold the
> pointer to the bitmap.  But most gimple assignments are to temporaries
> variables, and these don't need annotations.  Creating different kinds
> of gimple assignments would make things quite complex, so I'd rather
> not go down that path.  So, you'd use a lot more memory, even when the
> feature is not in use at all, and you might likely use more memory
> than adding separate notes for user assignments like I do.  And this
> doesn't even count the actual bitmaps.

I expect that most compilations are with -g, so I think we need to
compare memory usage between the two approaches with -g.


I don't know what the best approach is for improving debug
information.  But I think we've learned over time that explicit NOTEs
in the RTL was not, in general, a good idea.  They complicate
optimizations and they tend to get left behind when moving code.
We've fixed many many bugs and misoptimizations over the years due to
NOTEs.  I'm concerned that adding DEBUG_INSN in RTL repeats a mistake
we've made in the past.

Ian