[PATCH] D28368: Give higher full-unroll boosting when the loop iteration is small.

Dehao Chen via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Jan 5 15:38:58 PST 2017


danielcdh added a comment.

In https://reviews.llvm.org/D28368#637499, @mzolotukhin wrote:

> Hi,
>
> I don't think that a right approach for it. We already have a lot of thresholds and I'd prefer to avoid adding another one as much as possible.


Sorry that I don't seem to quite follow the comment. We did not add a new threshold in this patch, or am I missing something? Can you help clarify?

> In this particular case it also seems that we can express the same 'bonus' with existing thresholds. There is `unroll-max-iteration-count-to-analyze`, which you might want to play with - if your loops have higher trip-counts then this thresholds, we don't try to predict benefits of unrolling and behave conservatively. Increasing this threshold should help unrolling more loops. If for some reason you don't want to change this parameter, then you can get almost the same effect as you propose by just bumping up `unroll-threshold`.
> 
> Please also note that we already take into account the fact that unrolling removes branches: see `getUnrolledLoopSize`.

Yes and we model that in the original getFullUnrollBoostingFactor. This patch tried to model the other benefit: expanding optimization scope.

> Also, please also provide results of compile time testing for such changes.
> 
> Michael




https://reviews.llvm.org/D28368





More information about the llvm-commits mailing list