[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
Fri Jan 6 12:28:18 PST 2017


mzolotukhin added a comment.

> Agree that we need more accurate model, but the problem is that even the model is 100% accurate, linear-boosting factor cannot help boost threshold big enough for our case.

One problem with current cost model is that it's used for estimating both code size and runtime performance. It might be worth checking if we can gain anything from separating these two metrics more clearly - I think it was discussed in the past, but no decision has been made.

> I agree profile can help get a good balance here, but https://reviews.llvm.org/owners/package/2/ build cannot benefit from it.

There are always cases where we generate sub-optimal code. For users striving for the outmost performance we provide higher optimization levels (+LTO, +PGO) and pragmas. We cannot just bump thresholds for every case we want to unroll/inline/whatever.

> Sorry, I meant the profile I proposed in this patch.

Adding `Constant/TripCount` looks like simply bumping the threshold to me, except it also adds complexity to the code, so I'm not convinced we want this.

Michael


https://reviews.llvm.org/D28368





More information about the llvm-commits mailing list