Hi, On Fri, 23 Nov 2007, Alexandre Oliva wrote:
> Yep. Nowhere does that bug report request parameters to be forced live. Not in that bug report perhaps, but we got requests for exactly this, i.e. to be able to introspect all parameters of all functions, be they inlined or not, at all time. I think that's a reasonable request even (which in some situations comes at a cost). > 2. function is inlined, the argument is unused and thus optimized > away, but the function does some other useful computation > > At the inlined entry point, we have a note that binds the argument to > its expected value. As we transform the program and optimize away the > argument, we retain and update the note, As far as possible. If it's not possible you loose (with our requirements). > > For us it also happened in the kernel in namei.c, where real_lookup is > > inlined sometimes, and it's arguments are missing. That might or > > might not be reversible functions, so your scheme perhaps would have > > helped there. But generally it won't solve the problem for good. > > It looks like you're trying to solve a different problem. We work on two fronts: 1) increasing the precision of debug information 2) forcing values life Our branch, and our ssa-name<->user-name map (and the SET<->decls association) is concerned with the first topic. The second topic can be implemented (or hacked) already now, but will potentially be more usefull when we also have (1). So, as in your branch, we are not trying to limit optimizers to reach the goal, that's the concern of (2), and happens somewhere else. > I'm trying to get GCC to emit debug information that correctly matches > the instructions it generated. > > If the value of a variable is completely optimized away at a point in > the porogram, the correct representation for its location at that point > is an empty set. I think this is academic. If a value is dead, but happens to lie in a place which isn't yet overwritten with something else, it is harmless to reveal this value. It's the "last" value the variable had. If OTOH the place _is_ already overwritten then it's important that we _don't_ say the dead variable lies therein. So, for me correctness is defined a bit different than for you: 1) if location L contains value X, then debug info should say so (as much as possible, i.e. here the quality of the info comes into play) 2) if location L does not contain value X, debug info should not say that it does. This is the correctness part. Where we differ in opinion (I think) is, when location L doesn't contain value X anymore. For you it's when X becomes dead. For me it's when X is dead and when location L is overwritten (with something different than X). I think for users there is no practical difference between our approaches, but there's a higher cost of implementation for your definition. > > Then I'm probably still confused what problem you're actually trying to > > solve. If you don't want to be sure you get precise location information > > 100% of the time, then what percentage are you required to get? > > Accuracy comes first. If we ever emit debug information saying 'this > variable is here' for a point in the program in which it's in fact > elsewhere I agree here ... > or unavailable, that's a bug to be fixed. ... and disagree here. If a value is dead it's not necessarily unavailable in my world. I think a world requiring this (and hence the constraints you were given) is unreasonable. Ciao, Michael.
