[PATCH] Calculate vectorization factor using the narrowest type instead of widest type

[Chandler Carruth]

I've replied to some of the higher level concerns already, but I wanted to
point out one specific thing:

On Fri, Apr 10, 2015 at 3:30 AM Cong Hou <congh at google.com> wrote:

> LLVM uses the widest type to calculate the maximum vectorization factor,
> which greatly limits the bandwidth of either calculations or loads/stores
> from SIMD instructions. One example is converting 8-bit integers to 32-bit
> integers from arrays in a loop: currently the VF of this simple loop is
> decided by 32-bit integer and for SSE2 it will be 4. Then we will have 1
> load and 1 store in every 4 iterations. If we calculate VF based on 8-bit
> integer, which will be 16, we will have 1 load and 4 stores in every 16
> iterations, saving many loads.
>

While I'm generally in favor of this kind of change, I think the test case
you're looking at is actually a separate issue that I've written up several
times w.r.t. our vectorizer.

Because C does integer promotion from 8-bit integer types to 32-bit integer
types, we very commonly see things that are vectorized with 32-bit integer
math when they don't need to.

The IR can't narrow these operations from 32-bit integer operations to
8-bit integer operations without losing information because in 8-bits the
operations might overflow. But when vectorizing, we don't care about this.
We should aggressively narrow operations above a trunc which we could hoist
the trunc above by stripping overflow flags while building the vectorizable
operation tree so that we can fit more operations into a single vector.
Does that make sense?

-Chandler


>
> This patch mainly changes the function getWidestType() to
> getNarrowestType(), and uses it to calculate VF.
>
> http://reviews.llvm.org/D8943
>
> Files:
>   lib/Target/X86/X86TargetTransformInfo.cpp
>   lib/Transforms/Vectorize/LoopVectorize.cpp
>   test/Transforms/LoopVectorize/X86/fp64_to_uint32-cost-model.ll
>   test/Transforms/LoopVectorize/X86/vector_ptr_load_store.ll
>
> EMAIL PREFERENCES
>   http://reviews.llvm.org/settings/panel/emailpreferences/
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150414/210e734e/attachment.html>