another SCEV surprise

When compile the following case and look at the SCEV analysis, I notice that the first two loops don’t have a LoopInvariantBackedgeTakenCount (surprising) and the last one does (not surprising, except in the context of the first two examples).

void p4(int *A, int *B, long int n) {

for (char i = 0; i < n; i++) {

A[i + 2] = i;

*B++ = A[i];

}

}

void p5(int *A, int *B, long int n) {

for (short i = 0; i < n; i++) {

A[i + 2] = i;

*B++ = A[i];

}

}

void p6(int *A, int *B, long int n) {

for (int i = 0; i < n; i++) {

A[i + 2] = i;

*B++ = A[i];

}

}

Why the difference? Is there a reason we don’t implement all the loops using 64-bit values?

Thanks,
Preston

The third loop is provably not an infinite loop, thanks to C's signed
overflow rules; we can't tell whether the first two loops might be
infinite.

-Eli

> When compile the following case and look at the SCEV analysis, I
> notice that the first two loops don't have a
> LoopInvariantBackedgeTakenCount (surprising) and the last one does
> (not surprising, except in the context of the first two examples).
>
> void p4(int *A, int *B, long int n) {
> for (char i = 0; i < n; i++) {
> A[i + 2] = i;
> *B++ = A[i];
> }
> }
>
> void p5(int *A, int *B, long int n) {
> for (short i = 0; i < n; i++) {
> A[i + 2] = i;
> *B++ = A[i];
> }
> }
>
> void p6(int *A, int *B, long int n) {
> for (int i = 0; i < n; i++) {
> A[i + 2] = i;
> *B++ = A[i];
> }
> }
>
>
> Why the difference? Is there a reason we don't implement all the
> loops using 64-bit values?

The third loop is provably not an infinite loop, thanks to C's signed
overflow rules; we can't tell whether the first two loops might be
infinite.

This seems like a perfect example of where LLVM might want to emit a
note to the user (especially when we have loop vectorization and other
transformations).

-Hal

Thanks Eli.

Hal, yes, I agree. I imagine producing an listing with all sorts
of annotations concerning the success/failure of vectorization
and other loop xforms. Seems pretty essential as a tool to
help the performance-oriented programmer understand what’s
happening in the compiler. Serves as a feedback mechanism,
teaching programmers what sorts of code can/can’t be analyzed
and transformed.

Preston