Alexandre Oliva <[EMAIL PROTECTED]> 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
