[PATCH] D74944: [LoopVectorize] Fix cost for calls to functions that have vector versions

[Nemanja Ivanovic via Phabricator via llvm-commits]

nemanjai added a comment.

I am not sure I am actually following what it is you are requesting in terms of testing. Perhaps I need to describe the problems I am solving more thoroughly.

1. The actual failure only happens with MASSV as far as I can tell. I've actually tried very hard to find a situation in which it can happen with other vector libraries, to no avail. I'll explain why below.
2. I have added a test case that runs the entire pipeline with the `-vector-library` option as well as a test case that omits the pass that adds the attributes - i.e. a test for which the vectorizer uses the provided attributes.
3. The problem is precisely a missing vector function for a vectorization factor of 4, so I am not sure how it would help if I provided an attribute for a fictional function that covers such a vectorization factor.

So why is this uniquely a PPC/MASSV problem?
For the `SVML` library, no attempt will ever be made to select a vectorization factor wider than 8 (since the largest vector register the X86 back end specifies is 256). Since all the functions for `SVML` have a VF=8 variant, the problem will never happen. We can artificially force the problem to happen with `SVML` if we use the same test case and `--force-vector-width=16`. But I don't think that is representative of real-world code.
For the `Accelerate` library, there are only entries for the `f32` type so we will never attempt to vectorize to anything wider than a factor of 4. Of course, we can artificially force the assert with the same option.
I am not opposed to adding two test cases I just described, but I think they will be artificial and superfluous since the problem is the same regardless of the vector library used.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74944