------- Comment #5 from jakub at gcc dot gnu dot org 2010-03-02 13:48 -------
The disadvantage of clearing cur_loc in check_changed_vars_{1,2} is that we'd
lose track of the preferred location.
I guess we want to prefer the previous cur_loc (at least if it in the end
results in REG or MEM or if no new REG or MEM possibility appeared - preferring
REG or MEM means the value can be actually changed instead of just inspected)
then if that fails and the VALUE/DEBUG_EXPR_DECL in question didn't have
cur_loc updated during the current emit_notes_for_changes call and it is
actually a changed variable, loop through the location list, consider other
alternatives and update cur_loc. When we've changed a cur_loc of a
VALUE/DEBUG_EXPR_DECL once, we shouldn't change it again during the same
emit_notes_for_changes call though (and when it is not in the changed_variables
set we shouldn't change it at all, just use cur_loc and if that fails, fail).
If we did the checking in check_changed_vars_{1,2} instead, we could add to the
changed_vars set further variables, on the other side it might be more
expensive, as we'd need to basically duplicate the hash table lookups
vt_find_loc_callback performs. For the vt_find_loc_callback alternative we'd
have to avoid flushing VALUEs/DECL_DEBUG_EXPRs from the changed_variables hash
table immediately (and set_dv_changed (dv, false)), would need a second hash
table walk for that, so that we are able to differentiate between changed and
non-changed variables. We could cache the cur_loc lookups though, e.g. in a
union with offset field.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43176
