[PATCH] D18670: LoopUnroll: some small fixes/tweaks to make it more useful for partial unrolling

[Z. Zheng via llvm-commits]

zzheng added a comment.

In http://reviews.llvm.org/D18670#389000, @escha wrote:

> FullUnrollMaxCount isn't used anywhere because it's a TTI option used by our out of tree target.


If it's not used by target-independent unroll pass, perhaps you can put it in your TTI?

> Count is a force-unroll option; it doesn't have anything to do with this, as far as I know.

>  ...make reasonable judgements as to how much unrolling is reasonable given that number


That's what UP.Count is intended to do: let the target suggest an unroll count it deems reasonable.

> MaxCount is what I would want, but it *specifically does not apply to full unrolling*, as specified in the documentation. I want to limit the number of iterations for a full unroll.

> 

> PartialThreshold, again, has nothing to do with full unrolls.




  unsigned Count = UP.Count;
  bool CountSetExplicitly = Count != 0;                                                                   
  // Use a heuristic count if we didn't set anything explicitly.                                          
  if (!CountSetExplicitly)
    Count = TripCount == 0 ? DefaultUnrollRuntimeCount : TripCount;
  if (TripCount && Count > TripCount)
    Count = TripCount;

If Count, derived from UP.Count, (again, suggested by the target), is smaller than TripCount, it becomes partial unrolling and PartialThreshold/MaxCount applies automatically.

I'd add TripCount to UP so TTI::getUnrollingPreferences() can knowingly setup partial unrolling.

> > I don't quiet understand the term 'put a cap on full unrolling'... If we can't unroll by compile-time-known tripcount, it becomes partial unrolling, right?

> 

> 

> Yes, exactly. If the compile-time known tripcount is greater than FullUnrollMaxCount, it will fall back to partial unrolling instead, because it cannot do a full unroll.


It seems partial unrolling is preferred over full unrolling for your target. I would set it up in getUnrollingPerferences()... unless it's too early for the TTI to estimate how much unrolling is suitable during LoopUnrollPass.


Repository:
  rL LLVM

http://reviews.llvm.org/D18670