search for: loopvectorizationlegality

...n going forward (http://www.llvm.org/docs/Proposals/VectorizationPlan.html). All VP*Recipe class definitions are now moved to VPlan.h, and I have a patch under review to move LoopVectorizationPlanner class out of LoopVectorize.cpp (https://reviews.llvm.org/D41420). Next thing I'm working on is LoopVectorizationLegality, and I noticed that it has a component of CostModel and optimization, which doesn't seem right from vectorizer's architectural perspective. It appears that we are currently abusing Legal as the attic to throw a lot of things in order to avoid passing many pointers around. From vectorizer...

...p://www.llvm.org/docs/Proposals/VectorizationPlan.html). All VP*Recipe class definitions are now > moved to VPlan.h, and I have a patch under review to move LoopVectorizationPlanner class out of > LoopVectorize.cpp (https://reviews.llvm.org/D41420). > > Next thing I'm working on is LoopVectorizationLegality, and I noticed that it has a component of > CostModel and optimization, which doesn't seem right from vectorizer's architectural perspective. > It appears that we are currently abusing Legal as the attic to throw a lot of things in order to avoid passing > many pointers around. Fro...

...t;spatel at rotateright.com>; Simon Pilgrim <llvm-dev at redking.me.uk>; Tian, Xinmin <xinmin.tian at intel.com>; Nema, Ashutosh <Ashutosh.Nema at amd.com> > Subject: Re: [llvm-dev] RFC: [LV] any objections in moving isLegalMasked* check from Legal to CostModel? (Cleaning up LoopVectorizationLegality) > >> On 5 Jan 2018, at 21:01, Saito, Hideki via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> >> All, >> >> I'm trying to refactor LoopVectorize such that it has better >> conformance to VPlan vision going forward >> (http://www.llv...

...el <spatel at rotateright.com>; Simon Pilgrim <llvm-dev at redking.me.uk>; Tian, Xinmin <xinmin.tian at intel.com>; Nema, Ashutosh <Ashutosh.Nema at amd.com> Subject: Re: [llvm-dev] RFC: [LV] any objections in moving isLegalMasked* check from Legal to CostModel? (Cleaning up LoopVectorizationLegality) > On 5 Jan 2018, at 21:01, Saito, Hideki via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > All, > > I'm trying to refactor LoopVectorize such that it has better > conformance to VPlan vision going forward > (http://www.llvm.org/docs/Proposals/Vectorizat...

...el <spatel at rotateright.com>; Simon Pilgrim <llvm-dev at redking.me.uk>; Tian, Xinmin <xinmin.tian at intel.com>; Nema, Ashutosh <Ashutosh.Nema at amd.com> Subject: Re: [llvm-dev] RFC: [LV] any objections in moving isLegalMasked* check from Legal to CostModel? (Cleaning up LoopVectorizationLegality) On 01/05/2018 06:28 PM, Saito, Hideki wrote: > Amara, > >> I support this direction > Thanks for the support. > >> but are there actually any real world workloads where gather/scatter scalarisation would be worth it, on any micro-architecture? If we don’t have examples an...

...g> Cc: Saito, Hideki <hideki.saito at intel.com> Subject: Re: [llvm-dev] 6 separate instances of static getPointerOperand(). Time to consolidate? "Saito, Hideki via llvm-dev" <llvm-dev at lists.llvm.org> writes: > LLVM friends, > > I'm currently trying to make LoopVectorizationLegality class in > Transform/Vectorize/LoopVectorize.cpp more modular and eventually move > it to Analysis directory tree. It uses several file scope helper > functions that do not really belong to LoopVectorize. Let me start > from getPointerOperand(). Within LLVM, there are five other sim...

...at 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 be applied to, which is, at best, backwards. When...

...which does NOT get vectorized with my version of LoopVectorize, although it's simple to reason it's trivial to vectorize. One more question: how can I obtain an expression for the bounds and the step of the original loop? For example, when I print the ScalarEvolution object in LoopVectorizationLegality::isConsecutivePtr(), I can get the value reported in "Exits" for the indvars.iv instruction which is the upper bound for the loop getting vectorized. Thank you, Alex

Hello, i have been working with an accelerator backend. the accelerator has large vector/simd units. i want streaming loops (non-temporal) vectorized present in code to be offloaded to accelerator simd units. i find polly really suitable for this. i am thinking if the generated IR is passed to polly and then it analyzes loop to know it posses no reuse, if such loop is identified accelerator

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

Hi all, One of the reasons the Livermore Loops couldn't be vectorized is that it was using global structures to hold the arrays. Today, I'm investigating why is that so and how to fix it. My investigation brought me to LoopVectorizationLegality::canVectorizeMemory(): if (WriteObjects.count(*it)) { DEBUG(dbgs() << "LV: Found a possible read/write reorder:" << **it <<"\n"); return false; } In the first pass, it registers all underlying objects for writes, than...

...rote: > Hi, > > you could use Polly to generate an AstInfo. With the option > -polly-ast-detect-parallel it will mark loops in the generated Ast as > "coincident", i.e. parallel and without reuse. > > If you know the vector width of your accelerator, you can use > LoopVectorizationLegality::canVectorize to determine whether you can > vectorize it. If your accelerators computational model assumes no > loop-carried dependencies, maybe LoopVectorizationLegality can be > modified to accept 'infinite' vector width. > > polly-dev at googlegroups.com would be the mail...

...ainderVectorizePass. You can then read the metadata and try to vectorize the loop with half the VF. This will result in another remainder loop. Attach (or modify) the metadata with the halved VF. 3) You may have to do some cleanup of primary IV between LoopVectorize and RemainderVectorize. If LoopVectorizationLegality chokes in RemainderVectorize (i.e., thinks the loop is not legal to vectorize), try resolving what it is complaining. Legality should be the same between main vector loop and remainder ------ in theory. 4) Once you get to that point, just run RemainderVectorize enough times, until VF is small...

LLVM friends, I'm currently trying to make LoopVectorizationLegality class in Transform/Vectorize/LoopVectorize.cpp more modular and eventually move it to Analysis directory tree. It uses several file scope helper functions that do not really belong to LoopVectorize. Let me start from getPointerOperand(). Within LLVM, there are five other similar functions defined....

Hi, > On Apr 22, 2016, at 8:27 PM, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Rob, > > The problem here is that the d[i] array is only conditionally accessed, and so we can't if-convert the loop body. The compiler does not know that d[i] is actually dereferenceable for all i from 0 to 15 (the array might be shorter and p[i] is 0 for i past the end

...in <renato.golin at linaro.org> wrote: > Hi all, > > One of the reasons the Livermore Loops couldn't be vectorized is that it was using global structures to hold the arrays. Today, I'm investigating why is that so and how to fix it. > > My investigation brought me to LoopVectorizationLegality::canVectorizeMemory(): > > if (WriteObjects.count(*it)) { > DEBUG(dbgs() << "LV: Found a possible read/write reorder:" > << **it <<"\n"); > return false; > } > > In the first pass, it registers all...

...(const ValueToValueMap &Strides) { > 1029 if (isUniform(Ptr)) { > 1030 hasLoopInvariantStore = true; > 1031 } > > So later optimization can use this information in their legality analysis and make specific actions. > i.e. LoopVectorizer: > > 4002 bool LoopVectorizationLegality::canVectorizeMemory() { > 4008 if (LAI->hasLoopInvariantStore) { > 4009 emitAnalysis(VectorizationReport() > 4010 << "write to a loop invariant address could not be vectorized"); > 4011 DEBUG(dbgs() << "LV: We don't allow storing to...

"Saito, Hideki via llvm-dev" <llvm-dev at lists.llvm.org> writes: > LLVM friends, > > I'm currently trying to make LoopVectorizationLegality class in > Transform/Vectorize/LoopVectorize.cpp more modular and eventually move > it to Analysis directory tree. It uses several file scope helper > functions that do not really belong to LoopVectorize. Let me start > from getPointerOperand(). Within LLVM, there are five other similar...

Hi Ashutosh, > On Mar 16, 2015, at 9:06 PM, Nema, Ashutosh <Ashutosh.Nema at amd.com> wrote: > > Hi Adam, > > From: Adam Nemet [mailto:anemet at apple.com <mailto:anemet at apple.com>] > Sent: Wednesday, March 11, 2015 10:48 AM > To: Nema, Ashutosh > Cc: llvmdev at cs.uiuc.edu <mailto:llvmdev at cs.uiuc.edu> > Subject: Re: [LLVMdev] RFC: Loop

...(const ValueToValueMap &Strides) { > 1029 if (isUniform(Ptr)) { > 1030 hasLoopInvariantStore = true; > 1031 } > > So later optimization can use this information in their legality analysis and make specific actions. > i.e. LoopVectorizer: > > 4002 bool LoopVectorizationLegality::canVectorizeMemory() { > 4008 if (LAI->hasLoopInvariantStore) { > 4009 emitAnalysis(VectorizationReport() > 4010 << "write to a loop invariant address could not be vectorized"); > 4011 DEBUG(dbgs() << "LV: We don't allow storing to...