https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90231
--- Comment #11 from bin cheng <amker at gcc dot gnu.org> --- (In reply to Richard Biener from comment #9) > (In reply to bin cheng from comment #7) > > The orignal iv needs to be represented in debug bind stmt is: > > 64 IV struct: > > 65 SSA_NAME: i_18 > > 66 Type: int > > 67 Base: 0 > > 68 Step: 1 > > 69 Biv: Y > > 70 Overflowness wrto loop niter: No-overflow > > > > While the possible candidate is: > > 185 Candidate 8: > > 186 Var befor: ivtmp.11 > > 187 Var after: ivtmp.11 > > 188 Incr POS: before exit test > > 189 IV struct: > > 190 Type: unsigned long > > 191 Base: (unsigned long) dst_10(D) > > 192 Step: 4 > > 193 Object: (void *) dst_10(D) > > 194 Biv: N > > 195 Overflowness wrto loop niter: Overflow > > > > Strictly speaking, with above information, we can't compute i_18 using > > ivtmp.11 correctly in all cases, because ivtmp.11 could overflow. Of > > course, the overflow-ness in this case could be improved, thus solve the > > problem. Or there is another method: we can do the computation anyway, it > > may give wrong value in some cases, but we are in debug stmt, value which is > > correct in most cases is better than optimized away, sensible? > > Actually we do know that ivtmp.11 doesn't overflow. > > Since we can express the use of i in dst[i] by the new IV we can express > i in terms of the new IV at the point of its original use as well, I see > no way the transform isn't bijective. The complication here is just It's bijective if we can choose candidate derived from the same class of induction variables as "i", however, code rewriting debug-stmt currently selects cand using simple heuristic, it's not guaranteed cand from right class would be chosen. Also we reuse existing iv_use -> iv_cand computation code in rewriting debug-stmt. > that we have to undo the 'use in dst[i]' effect somehow, but for simple > cases or rewrite_use_* this should be doable.
