[llvm] [vectorization] More flexibility for VFxIC (PR #138709)

[Serval MARTINOT-LAGARDE via llvm-commits]

Serval6 wrote:

> So the only differnence with the new options vs -force-vector-width/-force-vector-interleave-count is that the new options only get applied when the VF is not worse than the scalar loop according to the cost model?

Thank you very much for your feedback. That's exactly it; it's applied as soon as the VF is  not worse than the scalar loop according to the cost model.

> If the VF/IC choice is overriden, persumably because the cost model makes wrong choices, should we still rely on it to decide whether it is profitable (i.e. not worse than the scalar loop)? Do you have any data how the new options perform compared to the existing ones?

We're basing this on the cost model as the default behavior. Therefore, this allows less aggressive behavior than existing flags/pragmas.
As part of the paper, we were able to compare llvm's default behavior (VF0IC0 implies letting llvm choose its VF and IC) with the different CustomVF/CustomIC values that we found interesting.

> I am wondering how useful it is in general, as applying one VF for all loops in a module seems not granular enough. Ideally we would have a way to apply custom factors per-loop, or only modify the VF for a single loop.

We observed that for many application (typically weather forecase code with flat profile) this granular seems to be enough. Nonetheless we agree that finer grain approach, with pragmas could be of interest.

https://github.com/llvm/llvm-project/pull/138709