mirror of
https://github.com/RPCS3/llvm-mirror.git
synced 2024-11-25 20:23:11 +01:00
7d3e19f39a
The loop vectorizer will currently assume a large trip count when calculating which of several vectorization factors are more profitable. That is often not a terrible assumption to make as small trip count loops will usually have been fully unrolled. There are cases however where we will try to vectorize them, and especially when folding the tail by masking can incorrectly choose to vectorize loops that are not beneficial, due to the folded tail rounding the iteration count up for the vectorized loop. The motivating example here has a trip count of 5, so either performs 5 scalar iterations or 2 vector iterations (with VF=4). At a high enough trip count the vectorization becomes profitable, but the rounding up to 2 vector iterations vs only 5 scalar makes it unprofitable. This adds an alternative cost calculation when we know the max trip count and are folding tail by masking, rounding the iteration count up to the correct number for the vector width. We still do not account for anything like setup cost or the mixture of vector and scalar loops, but this is at least an improvement in a few cases that we have had reported. Differential Revision: https://reviews.llvm.org/D101726 |
||
---|---|---|
.. | ||
Analysis | ||
AsmParser | ||
BinaryFormat | ||
Bitcode | ||
Bitstream | ||
CodeGen | ||
DebugInfo | ||
Demangle | ||
DWARFLinker | ||
ExecutionEngine | ||
Extensions | ||
FileCheck | ||
Frontend | ||
Fuzzer | ||
FuzzMutate | ||
InterfaceStub | ||
IR | ||
IRReader | ||
LineEditor | ||
Linker | ||
LTO | ||
MC | ||
MCA | ||
Object | ||
ObjectYAML | ||
Option | ||
Passes | ||
ProfileData | ||
Remarks | ||
Support | ||
TableGen | ||
Target | ||
Testing | ||
TextAPI | ||
ToolDrivers | ||
Transforms | ||
WindowsManifest | ||
XRay | ||
CMakeLists.txt |