[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