search for: outerloops

Proposal for extending the Loop Vectorizer to handle Outer Loops ================================================================ Goal: ----- We propose to extend the innermost Loop Vectorizer to also handle outerloops (cf.[1]). Our aim is to best leverage the efforts already invested in the existing innermost Loop Vectorizer rather than introduce a separate pass dedicated to outerloop vectorization. This proposal will support explicit vector programming of loops and functions [2]. It also facilitates evaluating...

Hi Steve it seems the general consensus is that the patch feels like a work-around for a problem with LSR (and possibly other loop transformations) that introduces redundant instructions. It is probably best to file a bug and a few of your test cases. Thanks Gerolf > On Sep 10, 2015, at 4:37 PM, Steve King via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Thu, Sep 10, 2015

On Mon, Sep 21, 2015 at 11:13 AM, Wei Mi <wmi at google.com> wrote: > I have the same worry as Philip and Hal that the new LoopExitValues > pass may increase some live range significantly in certain cases > because it reuses value cross outerloop iterations. Like the following > hypothetical case, the value reuse will create a live range living > across loop2, loop3, .... But

On 7/1/20 12:40 AM, Michael Kruse via llvm-dev wrote: > To illustrate some difficulties with FileCheck, lets make a > non-semantic change in LLVM: > >     --- a/llvm/lib/Analysis/VectorUtils.cpp >     +++ b/llvm/lib/Analysis/VectorUtils.cpp >     @@ -642,8 +642,8 @@ MDNode *llvm::uniteAccessGroups(MDNode > *AccGroups1, MDNode *AccGroups2) { >          return AccGroups1;

Am Mi., 24. Juni 2020 um 10:12 Uhr schrieb David Blaikie <dblaikie at gmail.com>: > > As mentioned in the Differential, generating the tests automatically > > will lose information about what actually is intended to be tested, > > Agreed - and I didn't mean to suggest tests should be automatically > generated. I work pretty hard in code reviews to encourage tests to

Hi Folks, Let's keep this optimization alive. To summarize: several folks voiced general support, but with questions about why existing optimizations do not already catch this case. Deep dive by Wei Mi showed that the optimization is most likely not a clean-up of LSR sloppiness, but something new. Follow-up by myself confirmed that the redundancy eliminated the LoopExitValues pass exists in

The test as written is fragile because it requires a certain ordering. If the output order is not important, use CHECK-DAG rather than CHECK. This would be a failure to understand the testing tool. My experience, over a 40-year career, is that good software developers are generally not very good test-writers. These are different skills and good testing is frequently not taught. It’s easy to

...traction of the output IR, and the vector code generation is driven by this abstract representation.   This is a follow up of the previous RFCs and LLVM Developer Conference presentations:           http://lists.llvm.org/pipermail/llvm-dev/2016-September/105057.html (RFC: Extending LV to vectorize outerloops)           http://lists.llvm.org/pipermail/llvm-dev/2017-February/110159.html (RFC: Introducing VPlan to model the vectorized code and drive its transformation)           https://www.youtube.com/watch?v=XXAvdUwO7kQ (Extending LoopVectorizer: OpenMP4.5 SIMD and Outer Loop Auto-Vectorization)        ...

...G eventually becomes the abstraction of the output IR, and the vector code generation is driven by this abstract representation.   Please refer to the following for more detailed background:   RFCs        http://lists.llvm.org/pipermail/llvm-dev/2016-September/105057.html (Extending LV to vectorize outerloops)        http://lists.llvm.org/pipermail/llvm-dev/2017-February/110159.html  (Introducing VPlan to model the vectorized code and drive its transformation)   "Extending LoopVectorizer: OpenMP4.5 SIMD and Outer Loop Auto-Vectorization"  (Saito, et.al.) 2016 LLVM Developers' Meeting https...

...nd the vector code generation is driven by this abstract representation. > > This is a follow up of the previous RFCs and LLVM Developer Conference presentations: >            > http://lists.llvm.org/pipermail/llvm-dev/2016-September/105057.html > (RFC: Extending LV to vectorize outerloops) >           > http://lists.llvm.org/pipermail/llvm-dev/2017-February/110159.html > (RFC: Introducing VPlan to model the vectorized code and drive its > transformation) >           https://www.youtube.com/watch?v=XXAvdUwO7kQ (Extending > LoopVectorizer: OpenMP4.5 SIMD and Ou...

...neration is driven by this abstract representation. >> >> This is a follow up of the previous RFCs and LLVM Developer Conference presentations: >> >> http://lists.llvm.org/pipermail/llvm-dev/2016-September/105057.html >> (RFC: Extending LV to vectorize outerloops) >> >> http://lists.llvm.org/pipermail/llvm-dev/2017-February/110159.html >> (RFC: Introducing VPlan to model the vectorized code and drive its >> transformation) >>           https://www.youtube.com/watch?v=XXAvdUwO7kQ (Extending >> LoopVectorizer...

Hi all, I've taken preglows ARM versions of qmf_synth and iir_mem16 from rockboxes speex codec, and tweaked them a bit further for some more speed. I attach them here so you can review and take on any changes you want. Please let me know if you have questions etc. Thanks, Robin -- Robin Watts, Email: <mailto:Robin.Watts@wss.co.uk> Warm Silence Software, WWW:

> The compare of interest is clear, I think. It compares a Vector Induction Variable with a broadcasted loop invariant value, aka the BTC. Obtaining the latter operand is the goal, clearly, but to do so, the former operand needs to be recognized as a VIV. Yep, exactly that. > What if this compare is not generated by LV’s fold-tail-by-masking transformation? Not sure I completely follow

...by this abstract representation. >>>    This is a follow up of the previous RFCs and LLVM Developer >>> Conference presentations: >>>             >>> http://lists.llvm.org/pipermail/llvm-dev/2016-September/105057.html >>> (RFC: Extending LV to vectorize outerloops) >>>             >>> http://lists.llvm.org/pipermail/llvm-dev/2017-February/110159.html >>> (RFC: Introducing VPlan to model the vectorized code and drive its >>> transformation) >>>             https://www.youtube.com/watch?v=XXAvdUwO7kQ (Extending >...

Hi Ayal, Let me start with commenting on this: > A dedicated intrinsic that freezes the compare instruction, for no apparent reason, may potentially cripple subsequent passes from further optimizing the vectorized loop. The point is we have a very good reason, which is that it passes on the right information on the backend, enabling opimisations as opposed to crippling them. The compare