search for: innerloopvectorizer

I am seeing an assert when I run this command: $ clang -fno-strict-aliasing -target mips64el-unknown-linux -O3 -fomit-frame-pointer -S oggenc.i -o oggenc.ll -emit-llvm It asserts when LoopVectorize.cpp:506 is executed. It looks like it is complaining because it is trying to zero-extend an i64 (type Count->getType() returns i64) to an i32 (IdxTy). if (Count->getType() != IdxTy) { //

Please file a bug for these types of issues. On Fri, Dec 21, 2012 at 1:49 PM, Akira Hatanaka <ahatanak at gmail.com> wrote: > I am seeing an assert when I compile the attached program with clang: > > $ clang -fno-strict-aliasing -target mips64el-unknown-linux -O3 > -fomit-frame-pointer -S test1.c -o test1.ll -emit-llvm > > > It asserts when LoopVectorize.cpp:506 is

I am seeing an assert when I compile the attached program with clang: $ clang -fno-strict-aliasing -target mips64el-unknown-linux -O3 -fomit-frame-pointer -S test1.c -o test1.ll -emit-llvm It asserts when LoopVectorize.cpp:506 is executed. It looks like it is complaining because it is trying to zero-extend an i64 (type Count->getType() returns i64) to an i32 (IdxTy). if (Count->getType()

On 2/18/2019 4:15 AM, Michael Platings via llvm-dev wrote: > Taking my previous example [1]: > > InnerLoopVectorizer LB(L, PSE, LI, DT, TLI, TTI, AC, ORE, VF.Width, IC, > &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, loop...

...is responsible for the vector add of a number of vector elements multiple of VF * UF. There are 2 epilogues which makes things a bit strange - I am still trying to understand the code. Is it possible to explain to me where in LoopVectorize.cpp are created 2 vector.body blocks? I know that InnerLoopVectorizer::vectorize() calls InnerLoopVectorizer::createEmptyLoop() which creates the blocks required for vectorization, but I have difficulties to follow the classes instantiations. I ask because in fact, I would prefer having only one "vector.body" block for the above C program, as it was...

...n Mar 14, 2017, at 6:00 AM, Nema, Ashutosh <Ashutosh.Nema at amd.com >>>> <mailto:Ashutosh.Nema at amd.com>> wrote: >>>> >>>> Summarizing the discussion on the implementation approaches. >>>> Discussed about two approaches, first running ‘InnerLoopVectorizer’ >>>> again on the epilog loop immediately after vectorizing the original >>>> loop within the same vectorization pass, the second approach where >>>> re-running vectorization pass and limiting vectorization factor of >>>> epilog loop by metadata....

Summarizing the discussion on the implementation approaches. Discussed about two approaches, first running ‘InnerLoopVectorizer’ again on the epilog loop immediately after vectorizing the original loop within the same vectorization pass, the second approach where re-running vectorization pass and limiting vectorization factor of epilog loop by metadata. <Approach-2> Challenges with re-running the vectorizer pass: 1)...

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

...dam Nemet wrote: > >> On Mar 14, 2017, at 6:00 AM, Nema, Ashutosh <Ashutosh.Nema at amd.com >> <mailto:Ashutosh.Nema at amd.com>> wrote: >> >> Summarizing the discussion on the implementation approaches. >> Discussed about two approaches, first running ‘InnerLoopVectorizer’ >> again on the epilog loop immediately after vectorizing the original >> loop within the same vectorization pass, the second approach where >> re-running vectorization pass and limiting vectorization factor of >> epilog loop by metadata. >> <Approach-2> &gt...

...ave that limit, however, is that we don't model the costs of the checks. Not that the cost model is otherwise too inaccurate for low-trip-count loops. If we modeled the costs of the checks, then I don't think this would be a problem. > > 3) Technically speaking, constructing a new InnerLoopVectorizer to > vectorize this one loop sounds weird. We already have a worklist in > the vectorizer that's currently running. I agree, although we do want to reuse the cost and legality analysis (which I think is a worthwhile engineering decision because that analysis involves SCEV, AA, and TT...

According to the schedule (e.g. on the right on llvm.org), we should have tagged the release by now, but we haven't, so we're officially behind schedule. I'm still optimistic that we can wrap this up pretty soon, though. This is what's blocking us: - PR26509: Crash in InnerLoopVectorizer::vectorizeLoop() I'm waiting to hear what Cong comes up with, otherwise we can revert r255691 on the branch - Shrink-wrapping vs TLS: Davide and Quentin are working on it - PR26600: Loop vectorization creates an unsafe out-of-bounds load There's a patch out: http://reviews.llvm.org/D1...

...t;>> <Ashutosh.Nema at amd.com <mailto:Ashutosh.Nema at amd.com>> wrote: >>>>>> >>>>>> Summarizing the discussion on the implementation approaches. >>>>>> Discussed about two approaches, first running >>>>>> ‘InnerLoopVectorizer’ again on the epilog loop immediately after >>>>>> vectorizing the original loop within the same vectorization pass, >>>>>> the second approach where re-running vectorization pass and >>>>>> limiting vectorization factor of epilog loop by met...

...i64 1, i64 1> ... br i1 %10, label %for.cond.cleanup373, label %for.body10.preheader67 As you can see, %vec.phi has wrong incoming basic blocks. It could be as below. %vec.phi = phi <4 x i64> [ %8, %for.cond.cleanup972 ], [ zeroinitializer, %vector.body ] The problem comes from "InnerLoopVectorizer::fixNonInductionPHIs()". This function has assumption about the order of predecessors as below. // The predecessor order is preserved and we can rely on mapping between // scalar and vector block predecessors. for (unsigned i = 0; i < NumIncomingValues; ++i) { It seems it assu...

...ize if things go nice and smooth. If you opt to go with tweaking Ashutosh’s patch, Ashutosh’s patch (https://reviews.llvm.org/D30247 ) is doing what I wrote above within LoopVectorize (thus it can skip many things since data structures are still alive), through createVectorEpilog(), instantiating InnerLoopVectorizer inside InnerLoopVectorizer. That takes care of one remainder loop vectorization step. You need to modify so that it can do more than one step (like using an vector of EpilogLoopInfo). If you struggle in convincing LoopVectorizationLegality to think remainder is just as legal to vectorize as main ve...

...support in the near future LLVM IR gather and scatter intrinsics (as described at http://llvm.org/docs/LangRef.html#llvm-masked-gather-intrinsics and scatter)? I see you have defined some methods that should use them like: - bool isLegalMaskedGather(Type *DataType); - void InnerLoopVectorizer::vectorizeMemoryInstruction(Instruction *Instr) which defines a bool CreateGatherScatter, etc I gave to clang a simple vector add C program with step/stride 2 with flag "-avx2", but the resulting vector code does NOT use gather nor scatter. - did you try to consider patholo...

Something like: index 6db7f68..68564cb 100644 --- a/lib/Transforms/Vectorize/LoopVectorize.cpp +++ b/lib/Transforms/Vectorize/LoopVectorize.cpp @@ -1208,6 +1208,8 @@ void InnerLoopVectorizer::vectorizeMemoryInstruction(Instr Type *DataTy = VectorType::get(ScalarDataTy, VF); Value *Ptr = LI ? LI->getPointerOperand() : SI->getPointerOperand(); unsigned Alignment = LI ? LI->getAlignment() : SI->getAlignment(); + if (Alignment == 0) + Alignment = 1; unsigned Add...

...p-count check (i.e. speculatively executing them) and these are actually expensive operations? Is this is a cost-model problem being exposed by SimplifyCFG (which is hoisting these things outside of the trip-count check)? -Hal >> >> 3) Technically speaking, constructing a new InnerLoopVectorizer >> to vectorize this one loop sounds weird. We already have a >> worklist in the vectorizer that's currently running. > > I agree, although we do want to reuse the cost and legality > analysis (which I think is a worthwhile engineering decision > beca...

...rs get aligned on 2 bytes. This does not correspond to the preferred alignment for vectors that I specified in the data layout (which is bigger). Inspecting lib/Transforms/Vectorize/LoopVectorizer.cpp, there doesn't seem to be an intent of doing so. I looked at this method in particular: void InnerLoopVectorizer::vectorizeMemoryInstruction Is there a way (that I missed) to make this happen, or would it require a code change ? Or did I miss anything obvious ? Thanks in advance, - Benoit -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm...

...ber 15, 2013 4:05:53 PM > Subject: Re: [LLVMdev] Limit loop vectorizer to SSE > > > Something like: > > index 6db7f68..68564cb 100644 > --- a/lib/Transforms/Vectorize/LoopVectorize.cpp > +++ b/lib/Transforms/Vectorize/LoopVectorize.cpp > @@ -1208,6 +1208,8 @@ void > InnerLoopVectorizer::vectorizeMemoryInstruction(Instr > Type *DataTy = VectorType::get(ScalarDataTy, VF); > Value *Ptr = LI ? LI->getPointerOperand() : > SI->getPointerOperand(); > unsigned Alignment = LI ? LI->getAlignment() : SI->getAlignment(); > + if (Alignment == 0) > +...

...: Re: [LLVMdev] Limit loop vectorizer to SSE >> >> >> Something like: >> >> index 6db7f68..68564cb 100644 >> --- a/lib/Transforms/Vectorize/LoopVectorize.cpp >> +++ b/lib/Transforms/Vectorize/LoopVectorize.cpp >> @@ -1208,6 +1208,8 @@ void >> InnerLoopVectorizer::vectorizeMemoryInstruction(Instr >> Type *DataTy = VectorType::get(ScalarDataTy, VF); >> Value *Ptr = LI ? LI->getPointerOperand() : >> SI->getPointerOperand(); >> unsigned Alignment = LI ? LI->getAlignment() : SI->getAlignment(); >> + if (Alignme...