[llvm] [LoopUnroll] Introduce PragmaUnrollFullMaxIterations as a hard cap on how many iterations we try to unroll (PR #78648)

[David Blaikie via llvm-commits]

dwblaikie wrote:


> > Oh, the docs also say "#pragma unroll and #pragma unroll _value_ have identical semantics to #pragma clang loop unroll(full) and #pragma clang loop unroll_count(_value_) respectively. " - so that doesn't sound like `#pragma clang loop unroll(full)` would help the situation?
> 
> You're looking at some very old docs there. The current ones are https://clang.llvm.org/docs/AttributeReference.html#pragma-unroll-pragma-nounroll and they have the s/full/enable typo fixed.
Oh, right, thanks for spotting that.

Still - going to that documentation, then going down into the linked LanguageExtensions documentation mentions this: "If unroll(full) is specified the unroller will attempt to fully unroll the loop if the trip count is known at compile time identically to unroll(enable). However, with unroll(full) the loop will not be unrolled if the loop count is not known at compile time."

So that sounds like "unroll(full)" should unroll in fewer cases than "unroll(enable)"? But in this case, with this patch applied, it seems like the loop gets unrolled only with "unroll(full)" and not with "unroll(enable)"

> The unrolling heuristics are very complex and it's hard to make any definitive statements without a reproducer. Based on what you say, I _suspect_ that this patch has moved a partial unroll from happening in the full unroll pass to the runtime unroll pass and that exposed a second order compile-time issue in your case. Or it might be something else entirely...

Yep, we're working on reproducers & trying to talk through what we have until then in case it's helpful in the mean time.




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