> This is PR81179 I think, please mention that in the changelog.
Correct, my bad for missing that.
> This unconditionally pessimizes code even if there is no valid index
> zero, right?
Almost, since for a loop such as:
#define OFFSET 1
unsigned int find(const unsigned int *a, unsigned int v) {
unsigned int result = 120;
for (unsigned int i = OFFSET; i < 32+OFFSET; i++) {
if (a[i-OFFSET] == v) result = i;
}
return result;
}
the index i will match the contents of the index vector used here ---
but this does indeed pessimize the code generated for, say, OFFSET
= 2. It is probably more sensible to use the existing code path in those
situations.
> The issue with the COND_REDUCITION index vector is overflow IIRC.
Does that mean such overflows can already manifest themselves for
regular COND_REDUCTION? I had assumed sufficient checks were already in
place because of the presence of the is_nonwrapping_integer_induction
test.
