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

[hfinkel at anl.gov]

[+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?

Did you see any performance changes on the test suite?

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


http://reviews.llvm.org/D8943

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/