[PATCH] D108114: [LoopPeel] Peel if it turns invariant loads dereferenceable.

Florian Hahn via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Oct 7 13:05:21 PDT 2021


fhahn updated this revision to Diff 377986.
fhahn added a comment.

Bring the patch up to date again, address reviewer comments!

In D108114#2969919 <https://reviews.llvm.org/D108114#2969919>, @reames wrote:

> In D108114#2955727 <https://reviews.llvm.org/D108114#2955727>, @fhahn wrote:
>
>> In D108114#2951160 <https://reviews.llvm.org/D108114#2951160>, @reames wrote:
>>
>>> 
>>
>> I realize that the problem description missed a key bit of information: the motivating case has vectors passed through pointers, not references so deref is not guaranteed unfortunately.
>
> Shouldn't points to std::vectors still be deref_or_null?  If so, we should be able to prove non-null here.

I think I am missing something here. I tired to put toegether a reduced example: https://clang.godbolt.org/z/jfqKzzK5x . I don't see how `deref_or_null` on `%A`/`%B` would help here. We do not check of `%B` is null before executing the first load ` %B.start = load i64*, i64** %B.gep.start`.

>> AFAIK we do not iterate loop passes to a fixed point until no changes are made, I think we only execute them for each loop once (and new loops). Let me take a look and see on how re-composing the existing passes would look like.
>
> Honestly, I feel like we really should do either a) bounded iteration, or b) unroll the bounded iteration by hand a small handful of times.  The whole premise of the new PM was to allow conditional pass execution, this is a case where doing so is clearly "worth it".

I went back an experiemented with different pass-orderings. It looks like one other problem is that we cannot compute the backedge-taken count for the loop, because we cannot compute the exit count for the exit that depends on the load in the loop. There might be a way around that issue, but even then running `indvar,licm,simple-loop-unswitch` multiple times would still be a major shakeup of the pipeline I'd like to avoid for now, if possible.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D108114/new/

https://reviews.llvm.org/D108114

Files:
  llvm/include/llvm/Transforms/Utils/LoopPeel.h
  llvm/lib/Transforms/Scalar/LoopUnrollPass.cpp
  llvm/lib/Transforms/Utils/LoopPeel.cpp
  llvm/test/Transforms/LoopUnroll/peel-to-turn-invariant-accesses-dereferenceable.ll
  llvm/test/Transforms/PhaseOrdering/AArch64/peel-multiple-unreachable-exits-for-vectorization.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D108114.377986.patch
Type: text/x-patch
Size: 28313 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20211007/efb65436/attachment.bin>


More information about the llvm-commits mailing list