You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[lsr][term-fold] Restrict expansion budget, particularly for profiled loops
This is a follow up to an item I noted in my submission comment for
e947f95. I don't have a real world example where this is triggering
unprofitably, but avoiding the transform when we estimate the loop
to be short running from profiling seems quite reasonable.
A couple of observations:
* Because we already checked for affine addrecs, the worst expansion we're
going to see is the unknown trip count * unknown step case (both are
loop invariant). I picked a fallback cost (2 * SCEV's default expansion
budget of 4) which was high enough to allow this. These cases will
end up being somewhat rare anyways as finding one where we can prove
legality takes some work.
* Short running loops with constant trip counts produce either constant
expressions (if the step is constant) or multiplications by small
constant (if the step is unknown). Both of these are cheap by any
reasonable budget and thus not wroth checking for explicitly.
* Estimated trip counts come from profile data, loops without profile
data will not have one.
Overall, this doesn't end up making much of a difference in practical
behavior of the transform. Probably still worth landing, but I expect
this to be pretty low impact.
Possible future work (which I have no plans of doing at this time):
* Ppick the lowest cost alternate IV if we have multiple ones under the
budget.
* Use SCEV to prove a constant upper bound on the trip count, and restrict
the transform for unknown-but-small trip counts.
* I think we can now remove the affine restriction if we wanted. Would
need to think carefully about legality on this one.
I don't have examples where any of these would be profitable in practice,
but we'll see what comes up in the future.
0 commit comments