search for: vectorizationfactor

On Mon, 11 Feb 2019 at 23:20, Philip Reames via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I don't care about the convention, but I'm really not sure it's worth the churn which would result in the code base. The hurtle which needs cleared here is not "is it a better naming style", but "is the disruption implied by changing to the new convention

...p;LVL, &CM); > > If we imagine that over time it evolves such that 50% of the variables have been renamed to camelBack versions of the type names, then it will look like this: > > InnerLoopVectorizer LB(loop, PSE, loopInfo, DT, targetLibraryInfo, TTI, > assumptionCache, ORE, vectorizationFactor.Width, IC, > &loopVectorizationLegality, &CM); Hold on... The change from UpperCamel to lowerCamel should be separate from going from X to somethingOtherName. It seems like in this example, TLI is changed to targetLibraryInfo for the purpose of having a name that lowerCamel can b...

...roposal][RFC] Epilog loop vectorization +1 for “just rerun the vectorizer” on the scalar remainder loop, as the proposed decision process is broken down into “first determine best VF for main loop, then determine best next EpilogVF for remainder loop” anyhow: const LoopVectorizationCostModel::VectorizationFactor EpilogVF = CM.identifyNextProfitableVF(VF.Width); Raising some aspects: o The unroll factor may also affect the best EpilogVF. For instance, if UF=1 then EpilogVF < VF, as the patch currently enforces. But if UF is larger the next profitable EpilogVF could be equal to VF. o The scala...

On 02/22/2017 11:52 AM, Adam Nemet via llvm-dev wrote: > Hi Ashutosh, > >> On Feb 22, 2017, at 1:57 AM, Nema, Ashutosh via llvm-dev >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Hi, >> This is a proposal about epilog loop vectorization. >> Currently Loop Vectorizer inserts an epilogue loop for handling loops

...n >> >> +1 for “just rerun the vectorizer” on the scalar remainder loop, as the proposed decision process is broken down into “first determine best VF for main loop, then determine best next EpilogVF for remainder loop” anyhow: >> >> const LoopVectorizationCostModel::VectorizationFactor EpilogVF = >> CM.identifyNextProfitableVF(VF.Width); >> <> >> Raising some aspects: >> >> o The unroll factor may also affect the best EpilogVF. For instance, if UF=1 then EpilogVF < VF, as the patch currently enforces. But if UF is larger the ne...