https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90231
--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So, one possibility is for remove_unused_ivs to get_computation_at for all
candidates it is considering rather than just the best, or try best and if that
fails, try the others too and pick the best from among those that have some
computation.
Another problem is that get_computation_at fails even for the ivtmp.11_20
candidate. Now, perhaps we could have some argument to get_computation_at,
for_debug or similar, propagate it through the calls.
The reason it fails is:
else if (!constant_multiple_of (ustep, cstep, &rat))
return false;
ustep is 1, cstep is 4. Indeed, we can't express i_18 as use using
use = ubase - ratio * cbase + ratio * var
because we need division instead, so
use = ubase + (var - cbase) / ratio.
Now, for non-debug uses I'm quite sure this is never a good answer, division in
the loop is expensive, but for debug uses it is fine.
The question is if it is safe, what we've discussed earlier.
For the case of ivtmp.11_20 on x86_64 I think it is safe no matter what,
int is 32-bit, cstep / ustep is constant 4 and thus as long as the unsigned
long ctype is at least 34-bit, if there wasn't overflow on i_18, there won't be
on the other IV either (after the base is subtracted, if say the base was -16,
there would be a wrap of course, but we care about var - cbase).
On 32-bit arches we'd need to argue from the pointer arithmetics I guess,
something that isn't clear in the candidate.
