[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 16:28:02 PST 2017


danielcdh added a comment.

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

> > 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?
>
> Oh, my apologies. I implicitly agreed with what @hfinkel suggested and implied that we use a `cl::opt` parameter instead of the magic number `400`.
>
> > This patch tried to model the other benefit: expanding optimization scope.
>
> Ok, I understand the idea. However, it looks too vague to model, and I don't see a relation with tripcounts then. If a loop has a huge tripcount, and we completely unroll it, we'll get a huge single basic block with tons of optimization opportunities, right? How is it different for a loop with a smaller tripcount? Why does it depend on the tripcount at all, and why do we model it as a `400/TripCount`?


I see your point. Yes, the optimization scope is not related to trip count, and it is confusing to relate one with each other.

The real motivation for this patch is to boost the threshold for fully unroll so that we can materialize the performance benefits in our benchmarks. The initial thoughts were: simply boost unroll-threshold by a minimum of 2X for fully unrolling (which is fine to materialize the performance). But I think this might be harder to be accepted by upstream as it seems too brutal-force. Then I'm thinking of integrating trip_count into the model to limit the "relative code size increase".

Anyway, I think the patch needs to be updated to make it accurate. We could either use a constant minimum boosting factor, or still use the trip_count to limit "relative code size increase" but update the comment to make it accurate.

Any suggestions?

Thanks,
Dehao

> I think that we either need to be more explicit about what benefits we expect from unrolling (see e.g. what LoopUnrollAnalyzer does), or just use generic thresholds like `unroll-threshold`.
> 
> Michael




https://reviews.llvm.org/D28368





More information about the llvm-commits mailing list