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

Michael Zolotukhin via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Jan 5 16:15:22 PST 2017


mzolotukhin added a comment.

> 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 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