On Jun 4, 2011, Alexandre Oliva wrote: > On Feb 15, 2011, Alexandre Oliva wrote: >> VTA only tracks locations of gimple regs, while addressable variables >> still use the old var tracking strategy. This means addressable >> variables, during var-tracking, got locations that were not based on >> VALUEs, which failed immediately in the presence of auto-inc addresses. >> The locations also tended to degrade in other ways, when a register >> holding an address happened to be overwritten at a later point. >> This patch arranges for us to track addresses of these variables as >> VALUEs, and to emit new locations for them when a location whose value >> was used to compute its address changes, fixing the problem. >> The patch was regstrapped on x86_64-linux-gnu and i686-linux-gnu. Ok to >> install? > Ping? Retested on both platforms, unchanged except for fixing the typo > s/deug/debug/ in the ChangeLog entry, that Jakub caught. > http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00981.html Ping? Here's an updated patch that uses some of the recently-added infrastructure to notify dependent variables and values when their dependencies change. It didn't look reasonable to add a field to all variables parts, or even to all variables, just to hold a chain of loc_deps. For one-part variables, we reused cur_loc, but after some measurements I concluded it was perfectly ok to leave some backlinks behind or dangling, checking them on activation. It's not even a significant waste of memory: compare-debug bootstraps on x86_64- and i686-linux-gnu leave only 1 loc_exp_dep allocated in the pool I created for NOT_ONEPART loc_exp_deps in 3447 of the 5172 functions that leave any loc_exp_deps dangling off dependent values, at the end of var-tracking. Of all these 5172 functions, only 4 ever went beyond the initial pool allocation of 64 loc_exp_deps, which is less than 0.05%, with 98 as the highest count on the bootstraps. A 32 initial allocation would have been enough to cover 99.71% of the functions that have backlinks left behind at the end of var-tracking (thus released along with the pool), but since even 64 loc_exp_deps add up to as little as 512 pointers (half a 4KB page), I decided to leave it at that. Regstrapped on x86_64- and i686-linux-gnu. This ought to fix gcc.dg/guality/pr43077-1.c -O1 on powerpc (which is what the bug report is about), but I only verified that by examining a cross compiler output. Ok to install?