search for: maxvf

Hi, Current loop vectorizer uses a range of vectorization factors computed by MaxVF. For each VF, it setups unform and scalar info before building VPlan and the final best VF selection. The best VF is also selected within the VF range. for (unsigned VF = 1; VF <= MaxVF; VF *= 2) { // Collect Uniform and Scalar instructions after vectorization with VF. CM.collectUnifo...

...going to assume that the vectors can hold 256/32 == 8 single-precision values even though the real maximum is 4 values. How should we handle this? The loop vectorizer uses TTI to find the size of the vector register. It uses this number to calculate the maximum vectorization factor. The formula is MaxVF = (RegSize/LargestElementTypeSize). Next it checks for the costs of all of the possible vectorization factors from 1 (scalar) to MaxVF. I think that the best approach would be to improve the cost model because on blue gene <8 x float> ops would be more expensive than <4 x float>....

Nadav, et al., On the BG/Q, the vectors hold 4 double-precision values. For vectorizing single-precision code, there are single-precision-rounded instructions, and special load/store instructions, which allow the double-precision numbers to be treated as single-precision numbers. The problem is that the current vectorization code (in the BBVectorizer and, as far as I can tell, also in the

...d 256/32 == 8 > > single-precision values even though the real maximum is 4 values. > > How should we handle this? > > The loop vectorizer uses TTI to find the size of the vector register. > It uses this number to calculate the maximum vectorization factor. > The formula is MaxVF = (RegSize/LargestElementTypeSize). Next it > checks for the costs of all of the possible vectorization factors > from 1 (scalar) to MaxVF. > > I think that the best approach would be to improve the cost model > because on blue gene <8 x float> ops would be more expensive tha...

...model Hi David, This would be a very useful upgrade to the cost model. One thing I want to add is that we need to be mindful of the cases where the cost is proportional (or inversely proportional) to the VF, for instance in the LoopVectorizationCostModel::selectVectorizationFactor(ElementCount MaxVF), there is a point where expected cost is divided by the VF. I believe there are other places where the instruction cost is dependent on the actual number of elements in the vector. While this is not a problem for fixed vectors, for scalable vectors we need to account for the vscale component of th...

Hi, I'd like to propose a change to our cost interfaces so that instead of returning an unsigned value from functions like getInstructionCost, getUserCost, etc., we instead return a wrapper class that encodes an integer cost along with extra state. The extra state can be used to express: 1. A cost as infinitely expensive in order to prevent certain optimisations taking place. For example,

Thanks for looking into this. 1) Issues with re running vectorizer: Vectorizer might generate redundant alias checks while vectorizing epilog loop. Redundant alias checks are expensive, we like to reuse the results of already computed alias checks. With metadata we can limit the width of epilog loop, but not sure about reusing alias check result. Any thoughts on rerunning vectorizer with reusing