This patch removes a number of asserts that VF is not scalable, even though
the code where this assert lives does nothing that prevents VF being scalable.
Details
Diff Detail
Unit Tests
Time | Test | |
---|---|---|
390 ms | linux > HWAddressSanitizer-x86_64.TestCases::sizes.cpp |
Event Timeline
As far as I can tell these do sound OK, except perhaps for the one I put a question on.
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp | ||
---|---|---|
4896 | What happens if this function returns true? Do (predicated) scalars work OK for scalable vectors. |
llvm/lib/Transforms/Vectorize/LoopVectorize.cpp | ||
---|---|---|
4896 | If this function returns true, the operation would have to be scalarized. For scalable vectors, scalarization is only supported if the value is uniform after vectorization, so it can extract the first or last element. Scalarizing a non-uniform value is not supported, because there is currently no way to expand to a scalarization loop (and even if there would be, we probably wouldn't want to). From the comment in collectLoopUniforms (above addToWorklistIfAllowed), it seems that when isScalarWithPredication returns true, the value cannot be uniform. This means that the cost-model/legalization should prevent this from happening for scalable vectors. This is one of the reasons we're adding a new cost class in D91174 so that it would never pick a scalable VF when scalarization is required. There are currently other asserts that guard this case from happening, like in VPReplicateRecipe::execute. |
clang-format: please reformat the code