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

Cong Hou congh at google.com
Tue Apr 14 17:30:38 PDT 2015


On Sat, Apr 11, 2015 at 6:41 PM, hfinkel at anl.gov <hfinkel at anl.gov> wrote:

> [+Arnold, Nadav,Chandler]
>
> If I understand this correctly, this will cause us to potentially generate
> wider vectors than we have underlying vector registers, and I think that,
> generically, this makes sense. Now that our X86 shuffle handling is sane,
> the splitting of wide vectors, and shuffling that you get from vector
> extends/truncates is hopefully not too bad. Other opinions?
>

I agree that we need to refine the cost model for shuffling instructions,
by also considering the number of SIMD registers needed.


>
> Did you see any performance changes on the test suite?
>

I didn't see significant performance changes (actually I saw overall slight
2% performance improvement with this patch but am not sure if it is caused
by noise).


>
> We might need to update the register-pressure heuristic
> (LoopVectorizationCostModel::calculateRegisterUsage()) to understand that
> very-wide vectors use multiple vector registers.
>

Agree. So does it necessarily come with this patch?


>
>
> http://reviews.llvm.org/D8943
>
> EMAIL PREFERENCES
>   http://reviews.llvm.org/settings/panel/emailpreferences/
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150414/1781eec5/attachment.html>


More information about the llvm-commits mailing list