On Dec 19, 2007, "Daniel Berlin" <[EMAIL PROTECTED]> wrote:
>> Now, if z_5 were present in a debug expression, then it would need >> adjusting. No different from the adjusting need for any other >> instruction in which z_5 was present, though. > uh, but if you don't adjust in the fixed examples, DEBUG(x, x_4) will > give an invalid value. My point was that optimizers already had to know how to adjust things such that it doesn't break code. Now, in this optimization, it takes additional liberties with existing variables because it sees they're only used within the sequence. IMHO, it would be more appropriate to introduce alternate temporaries, rather than reusing SSA names for different purposes, in this case. If this approach was taken, the debug annotations referring to a no-longer-defined SSA name would be recognized as invalid, and the variable binding would be removed (i.e., turned into a "value unknown" annotation). Or, if we left the definitions in place, even though they're dead, the same code that cleans up undefined SSA names could recognize these SSA names as unused except in debug information and substitute them for their values, maintaining accurate and complete debug information. But can we do better without introducing more SSA names and keeping assignments around that are known to be dead? Yes, with some additional effort, see below. > How do i know i need to change this DEBUG expression. As reassoc looks for sets of variables it can freely mess with, it should take note of variables that are used in debug annotations in addition to the kind of single (?) non-debug uses it's interested in, such that, when it modifies these variables, the annotations can be compensated for. OTOH, if the compiler performs reassoc on user variables today, it means we do get mangled debug information for such variables already, and they get incorrect values. So, even if we didn't address this problem right away, it wouldn't be much of a regression. But, of course, not dealing with it breaks the goal of having correct debug information, so it ought to be dealt with properly. Do you happen to have a yummy testcase handy that I could use to trigger this kind of transformation in ways that affect the value of user variables? Thanks in advance, -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
