If the vectorized tree has truncate to minimum required bit width and
the vector type of the cast operation after the truncation is the same
as the vector type of the cast operands, count cost of the vector cast
operation as 0, because this cast will be later removed.
Also, if the vectorization tree root operations are integer cast operations, do not consider them as candidates for truncation. It will just create extra number of the same vector/scalar operations, which will be removed by instcombiner.
Details
Diff Detail
- Repository
- rL LLVM
- Build Status
Buildable 13991 Build 13991: arc lint + arc unit
Event Timeline
lib/Transforms/Vectorize/SLPVectorizer.cpp | ||
---|---|---|
4036–4038 | Yes, it is about initial roots. The main problem here is that these roots still must be analyzeв though not considered as candidates to demote. |
lib/Transforms/Vectorize/SLPVectorizer.cpp | ||
---|---|---|
4036–4038 | I honestly don't recall what the reason was. It probably had something to do with the way InstCombine wanted to rewrite the expression, given the trunc/ext sequence. I think what we should really try to do is make the type truncating code in InstCombine (EvaluateInDifferentType) a utility that we can use within the vectorizers. The trunc/ext trick is very fragile. We use it here in SLP,and in two separate places in LV to type-shrink reductions and other instructions. I'll finish taking a look at the rest of the patch shortly. |
Makes sense.