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

[James Molloy via llvm-commits]

Hi,

I agree with Chandler's comment in the review thread. I'm actively working
on a patch at the moment (it has a couple of correctness issues still to
resolve) to do this - identify operations that could be truncated and
performed in a narrower type, and update the cost model to understand this.

As far as I can see, what I have is a superset of your patch.

Cheers,

James

On Wed, 23 Sep 2015 at 12:51 hfinkel at anl.gov via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> hfinkel added a comment.
>
> Have you run LLVM's test suite with this turned on? Are there any
> significant performance changes? [I'm happy for this to go in, given that
> it's disabled by default, even if there are regressions to fix, but I'd
> like to know where we stand].
>
> .
>
>
> ================
> Comment at: lib/Transforms/Vectorize/LoopVectorize.cpp:4585
> @@ +4584,3 @@
> +    // Collect all viable vectorization factors.
> +    SmallVector<unsigned, 4> VFs;
> +    unsigned NewMaxVectorSize = WidestRegister / SmallestType;
> ----------------
> I'd make this 8 instead of 4 (we might have 7 VF for 8-bit integers in
> AVX-512, for example).
>
>
> http://reviews.llvm.org/D8943
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150923/152b6458/attachment.html>