What drives -loop-reduce to favor array indexing over pointer walking?

Project Infrastructure LLVM Dev List Archives
1

From the description in http://llvm.org/docs/Passes.html#loop-reduce-loop-strength-reduction I expected adding a -loop-reduce pass would transform a simple indexing by the loop variable into a pointer increment, i.e. effectively transforming this:

for(int a = 0; a < 64; a++) {
s += f(b[a]);
}

into this:

int*p = b;
for(int a = 0; a < 64; a++) {
s+= f(*p);
++p;
}

But on my toy CPU architecture I actually see the reverse, that the second loop gets converted by -loop-reduce from:

%p.01 = phi i8* [ %b, %entry ], [ %incdec.ptr, %for.body ]
%0 = load i8, i8* %p.01, align 1
%call = tail call i8 @_Z1fi(i8 %0)
%incdec.ptr = getelementptr inbounds i8, i8* %p.01, i8 1

to:

%scevgep = getelementptr i8, i8* %b, i8 %a.03
%0 = load i8, i8* %scevgep, align 1
%call = tail call i8 @_Z1fi(i8 %0)

I suspect it’s related to this comment in LoopStrengthReduce.cpp “it rewrites expressions to take advantage of scaled-index addressing modes available on the target” and that my toy architecture lacks appropriate modes (or incorrectly describes what it does have) but I haven’t seen what this interaction is. Any advice for where to start debugging / fixing my target handling?

Thanks!