[Bug debug/90231] ivopts causes <optimized away> iterator in the loop

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90231

--- Comment #8 from Jakub Jelinek <jakub 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?

I don't understand what kind of overflow you are worried about.
If the original IV didn't overflow, why would (int) ((unsigned long) ivtmp.11 -
(unsigned long) dst_10) ever not be a valid replacement for whatever was in
i_18?  Do you have an example where it would result in wrong-debug?
And yes, wrong-debug is worse than <optimized away>, but we could do things
like use a COND_EXPR in the debug_bind expression, if some condition is true,
use some expression how to compute the value, otherwise signal <optimized
away>.
But I don't understand why it would be needed in this case.