This is an archive of the discontinued LLVM Phabricator instance.

[LoopUnroll] Always respect user unroll pragma
ClosedPublic

Authored by Whitney on Feb 7 2022, 8:45 AM.

Details

Summary

IMO when user provide unroll pragma, compiler should always respect it.
It is not clear to me why loop unroll pass currently ensure that the unrolled loop size is limited by PragmaUnrollThreshold.

Diff Detail

Event Timeline

Whitney created this revision.Feb 7 2022, 8:45 AM
Whitney requested review of this revision.Feb 7 2022, 8:45 AM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 7 2022, 8:45 AM
Whitney updated this revision to Diff 406502.Feb 7 2022, 9:29 AM
Meinersbur added a comment.EditedFeb 8 2022, 3:13 PM

Added some reviewers for discussion.

The max unroll threshold for pragmas was already present from the very beginning: rGff9032459976cf309eda7a12a4b9c2deb4fb9d2b

I think the limit is there just to prevent the compiler from exploding. If you try to unroll too much, you're going to end up with effectively infinite compile time and/or run out of memory.

I would expect it's unlikely to trigger the limit in practice; do you have a practical case where it matters?

I think the limit is there just to prevent the compiler from exploding. If you try to unroll too much, you're going to end up with effectively infinite compile time and/or run out of memory.

I would expect it's unlikely to trigger the limit in practice; do you have a practical case where it matters?

We had a change to make certain kinds of instructions return InstructionCost::getMax() from getUserCost(), as we want to prevent optimizations like unrolling to happen for loops containing those instructions. (It is reverted.)
We were surprised to see that loops with user pragma were also affected. IMO it is user's responsibility to put pragmas that make sense.
IIUC if there is user pragma, we should always respect it. I don't feel too strongly about it, I mostly want to understand what's the level we want to respect user pragma to.

Meinersbur accepted this revision.Mar 29 2022, 6:37 PM

Unless @efriedma has further concerns, LGTM.

Review comments from D4090 and D4147 suggested much larger limits anyway.

This revision is now accepted and ready to land.Mar 29 2022, 6:37 PM
Herald added a project: Restricted Project. · View Herald TranscriptMar 29 2022, 6:37 PM

PragmaUnrollThreshold has other uses; are you intentionally leaving those alone?

I'm not confident it makes sense to "respect the user" here; nobody really benefits from crashing the compiler. But I don't have a strong preference here; "#pragma unroll" is rare enough that I don't expect much practical impact either way.

PragmaUnrollThreshold has other uses; are you intentionally leaving those alone?

Yes, it is still possible that shouldPragmaUnroll returns None, e.g., when (UP.AllowRemainder || (TripMultiple % PInfo.PragmaCount == 0)) is false.
And we want to be more aggressive with unrolling limits when given an unrolling pragma.

// If the loop has an unrolling pragma, we want to be more aggressive with                                                           
// unrolling limits. Set thresholds to at least the PragmaUnrollThreshold                                                            
// value which is larger than the default limits.

Thanks for your input.

Oh, I see, you still want to use the PragmaUnrollThreshold limit if the user tries to full-unroll a loop that can't be fully unrolled, or something like that. That makes sense.

This revision was landed with ongoing or failed builds.Apr 11 2022, 11:33 AM
This revision was automatically updated to reflect the committed changes.