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

[Florian Hahn via Phabricator via llvm-commits]

fhahn added a comment.

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

>> Do you have any pointers at the kind of speculation LICM could be doing? I could not spot anything that would be applicable after an initial look.
>
> LICM does two forms of legality reasoning for trap-safety.  Option 1 is guaranteed to execute.  Option 2 is proving that the hoisted load can't fault at the new location.  Looking at your test case (peel-multiple-unreachable-exits-for-vectorization.ll), option 1 does work (when iterated as you note).  Option 2 would require deref facts on the arguments A and B of @sum_2_at_with_int_conversion.  I don't see any reason why clang shouldn't be able to emit the deref info on those args?  (Assuming this is lowering a c++ reference to a std::vector<> at least.)  If it can, LICM should be able to speculate the loads for start and end from each vector outside the loop.

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.

>> What do you think? I think eliminating the separation between the 2 loop pass managers would be beneficial in its own right, but SimplifyCFG and InstCombine seems like a substantial gap to bridge.
>
> I agree with your reasoning all the way through.
>
> We'd previously explored the idea of adding loop versions of InstCombine and SimplifyCFG.  (See LoopSimplifyCFG, I don't remember where we stood on instcombine.)
>
> One mid-term idea would be to keep the split loop pass, but have the second one contain the same passes as the first.  (Essentially, we'd have one unrolled iteration of the loop iteration with the instcombine and simplifycfg in place.)  Though, actually, I don't remember, do we even iterate loop passes to fixed point if there are changes being made to the loop?  (All of my context on this involves an out of tree pass order which solves this with brute force repetition.)

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.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108114