[flang-commits] [flang] [flang] Add pass to version innermost loops on a likely constant trip count (1/2) (PR #231205)

[Caroline Newcombe via flang-commits]

cenewcombe wrote:

> Would it make sense to add a profitability threshold based on N × body size, in addition to max-section-extent? Even with a small constant trip count, LLVM may decline to fully unroll a large body, leaving us with an extra loop copy without the intended full-unroll benefit.

Yes, I did some testing and I think this makes sense. Based on my experiments  (a synthetic sweep over values of N and body ops), LLVM's `unroll-threshold` at `-O3` of 300 is the correct value to use. I added `max-unrolled-ops` (default 300, 0 disables the limit): a candidate is skipped when N x body ops exceeds the threshold, with a statistic to track the skips. The cost is that we give up any vectorizer-only benefit at large N, so this may be revisited with more data. For now the default avoids duplicating loops LLVM won't unroll, and the option is there for anyone who wants the other behavior.

> Another possible refinement would be to consider only array accesses that execute unconditionally on every iteration. An access under a conditional or after a possible early exit may not constrain the loop’s trip count, so its declared extent could be a weaker specialization candidate. Filtering such accesses might help avoid unnecessary duplication.

Agree, and the refinement is based on the access kind: an unsliced access `a(i)` is now required to be directly in the loop body block. A sliced access with triplet `(1, ub, 1)` constrains `ub` since the section designator `a(1:ub)` must be in bounds; so no change for this case. That keeps the `WHERE` case, which lowers to a `fir.if` around the store. There is no early exit case to cover as `fir.do_loop` is structured, and `fir.iterate_while` is already rejected in the innermost loop evaluation.

Thanks for these suggestions!

https://github.com/llvm/llvm-project/pull/231205