https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90231
--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> --- (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 that we have to undo the 'use in dst[i]' effect somehow, but for simple cases or rewrite_use_* this should be doable. And no, debug info that is sometimes incorrect isn't preferable to <optimized out>. > Thanks, > bin
