[PATCH] D71053: [LV] Take overhead of run-time checks into account during vectorization.

[Florian Hahn via Phabricator via llvm-commits]

fhahn added a comment.

> While 1) may look like a better approach I see it as very problematic in practice. That's why I decided to go with the 2).

Sorry if I missed an earlier discussion about this, but why do you think that expanding the RT checks is very problematic in practice? Is it the cost of expanding the RT checks early (and maybe throwing them away later)?
I am currently experimenting with this approach to see if it is feasible to use size estimates to better decide on the number of runtime checks (including mem ptr checks), regardless of the vectorisation mode.

The approach in this patch seems to delay & interleave parts of cost-modelling with codegen and adds quite a bit of additional plumbing through the codebase to do so.

IIUC, the basic idea is to enable vectorisation , if the cost of `runtime checks + vector cost < scalar cost`?  I think this might be too relaxed, as the cost of the RT checks have to be paid, even if they fail and we execute the scalar loop. And I guess the larger the number of checks, the larger the probability of one failing. Something related also came up in https://bugs.llvm.org/show_bug.cgi?id=44662 . I am not yet sure what better alternatives are there though.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D71053