[llvm-dev] What drives -loop-reduce to favor array indexing over pointer walking?
Tyro Software via llvm-dev
llvm-dev at lists.llvm.org
Tue Aug 23 00:30:34 PDT 2016
>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!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160823/7c76d1ce/attachment.html>
More information about the llvm-dev
mailing list