[PATCH] D75981: [LV] Allow large RT checks, if they are a fraction of the scalar cost.

Evgeniy via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sun Aug 15 22:54:07 PDT 2021


ebrevnov added a comment.

> I think the main problem is that it isn't quite obvious why hard cut-offs on the runtime check complexity exist.
> I guess, to not generate some very large and ridiculous checks.

I believe those cut-offs exist for the single reason. There was no way to calculate "real" cost of SCEV generated instructions. Now there is support for that and we can/should simply take cost of runtime checks into account in cost model.

> But clearly, the current cut-offs are just bogusly low.
> But i also guess simply bumping them won't really solve the problem,
> so i guess we need to redefine them. But what is the right metric,
> especially if the trip count is not constant?
> Cost of a single scalar loop iteration?

May be not the best approach, but taking some reasonable average across applications works good enough. Another metric to consider is benefit from vectorization. Thus loops with expected 3x improvement should be more likely vectorized than 1.1x.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D75981/new/

https://reviews.llvm.org/D75981



More information about the llvm-commits mailing list