LGTM, but please wait for a couple of days for experts in this area to review: )

@lebedev.ri

It fails even if i bump those limits to 0.1M iterations.
This is clearly an infinite combine cycle.

If that's the case, isn't it more reasonable to replace the fatal_error with assert so that only developers sense that?

In D99481#2790122, @aqjune wrote:

Reduced .ll:

reduce.ll3 KBDownload

$ opt -instcombine -S -o - reduce.ll
LLVM ERROR: Instruction Combining seems stuck in an infinite loop after 100 iterations.
...

In D102594#2766167, @tejohnson wrote:

lgtm. this seems fine to me, but presumably we would have a compile error if there was ever a conflict in practice with one of these files?

Did a fully scan and modified more files that have the same issue.

In D102594#2762526, @ChuanqiXu wrote:

@david-arm Glad to know that. Thank you for the work!

@david-arm Hi David, there's a tiny issue of the commit that the llvm.experimental.stepvector intrinsic is not well indexed in the changes to Langref.rst, and now it resides under llvm.experimental.vector.splice. I guess it's not intended and leave a message here FYI:)

ping

@mkazantsev Could you commit this for me, thanks!
My commit access application has been approved so I'll commit by myself:)

ping

Add a test case.

@lebedev.ri Thanks, will add a test. Besides, the bug fixed in ea7ab5a42cd4 seems to have the same root cause.

@kuhar @lebedev.ri I'm lucky to have a test case which requires exactly 1001 times iteration thus aborts. And would it be better just break out rather than report a fatal error?

In D87879#2384112, @fhahn wrote:

Actually, could we get similar problems for dependencies other than output, eg if we have a conditional load that is later used?

Yes, there're similar cases our team have found related to data dependence that may prohibit interchange. And I'd like to spend more time to see if there's a sophisticated solution.

ping

@fhahn Thanks for the suggestions, please take another look.

add a test case