[PATCH] D134803: [LoopPeeling] Support peeling loops with non-latch exits

[Nikita Popov via Phabricator via llvm-commits]

nikic added a comment.

In D134803#3869970 <https://reviews.llvm.org/D134803#3869970>, @tra wrote:

> As I suspected, the hanging code is ~2.5MB of unoptimized IR, reduced to ~1MB after optimizations. The IR is thread-sync heavy, and it's hard to tell if anything is obviously wrong after it gets further massaged by ptxas into GPU instructions. :-(

In this test case, is there only a single additional loop being peeled? If there are multiple, is it possible to localize which one is the problematic one? Can you identify which of the removed conditions in canPeel() are the ones that are relevant? Does the problematic loop contain convergent instructions as speculated before?

Just some suggestions on how the problem could be narrowed a bit further.

> Would it be possible to introduce a cc1 option disabling this kind of peeling, so we have some sort of workaround until we figure out a better way to deal with the issue?

For the record, D136643 <https://reviews.llvm.org/D136643> has the opt option (I assume that's what you meant, a cc1 option would be unusual). I think that patch is too complicated as-is, but generally having a temporary option is fine.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134803