Alexandre Oliva wrote: > 1. introduce, early in compilation (when entering SSA), annotations > that map user-level variables whose location may vary throughout their > lifetime to implementation-level variables or expressions at every > point of assignment and PHI joins. > > 2. keep those annotations accurate throughout compilation, without > letting them interfere with optimizations, but making sure they are > kept up-to-date or marked untrackable. > > 3. in var-tracking, starting from the expressions in the annotations > and their equivalent expressions computed with a dataflow-globalized > cse analysis, emit traditional var-tracking var_location notes for all > variables. For variables that didn't start out as gimple regs, the > current debug info behavior should be preserved. > >> I think that most of the goals boil down to making sure that, at any >> point in the program, the debug information for a variable meets the >> following criteria: > >> (a) if the variable has not been optimized away, gives the location >> where that variable's current value can be found, or >> (b) if the variable has been optimized away, and the value is not a >> constant, says that the value is not available, or >> (c) if the variable has been optimized away, but is a constant, says >> what the constant value is > > yes, except that instead of constant and constant value, I'd put it as > 'computable expression from other live values'. > > And I'd say "locations" rather than just "location".
I agree; those are generalizations, of which my bullets are a needlessly constrained special case. (Of course, we can gradually approach "computable" by starting with "constant", and then adding more and more refinement, if we like.) >> But, how are we going to track this information? Algorithmically, what >> needs to change in the compiler to maintain this state? > > Most optimizations passes must already update uses of gimple or pseudo > regs they modify, so these will be taken care of automatically (which > is why I chose this representation). For the purposes of this discussion, let's assume that upon exit from SSA we still have the information we need. In particular, we know which SSA names correspond to which user variables. That tells us how to get the values of user variables at the points where their values are available, and also tells us when those variables do not have their values available. (We may already have lost some information, though. For example, given: i = 3; f(i); i = 7; i = 2; g(i); we may well have lost the "i = 7" assignment, so "i" might appear to have the value "3" right before we assign "2" to it, if we were to generate debug information right then.) The reason I want to make that assumption is that the part of this where the representation is in question is once we reach RTL, right? I guess I still don't really understand what you're doing at the RTL level. I understand the objectives. I understand some of the things you're claiming as virtues of DEBUG_INSN. What I don't understand is how it's actually going to work. What are the notes you're inserting? Do they just say "here is an RTL expression for computing the value of user-variable V at this point in the program"? Why does it make sense to have that, rather than notes on instructions that say what affect the instruction has on user variables? (For example, "this SET makes the value of V unavailable". Or "this SET makes the value of the V available in the destination register"?) As a meta-question, have you or anyone else on the list looked at the literature (IEEE/ACM, etc.) or how other compilers handle these problems? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
