search for: vplan

Status Update on VPlan ---- where we are currently, and what's ahead of us ==========================================================   Goal: ----- Extending Loop Vectorizer (LV) such that it can handle outer loops, via uplifting its infrastructure with VPlan. The goal of this status update is to summarize the progr...

Proposal for Outer Loop Vectorization Implementation Plan ============================================= ===== Goal: ===== Extending Loop Vectorizer (LV) such that it can handle outer loops, via VPlan infrastructure enhancements. Understand the trade-offs in trying to make concurrent progress with moving remaining inner loop vectorization functionality to VPlan infrastructure   =========== Background: =========== This is related to VPlan infrastructure project we started a while back, a project...

...14, 2017 1:10 PM To: Saito, Hideki <hideki.saito at intel.com>; llvm-dev at lists.llvm.org; renato.golin at linaro.org; aemerson at apple.com; mkuper at google.com; mssimpso at codeaurora.org; Simon Moll <moll at cs.uni-saarland.de>; hfinkel at anl.gov Subject: Re: [llvm-dev] [RFC][LV][VPlan] Proposal for Outer Loop Vectorization Implementation Plan One area that needs a bit of attention before work on this proceeds much further is testing.  The introduction of VPlan appears to have introduced a couple of bugs and exposed a couple of others.  Most of those are now fixed, but the proce...

...1:10 PM > To: Saito, Hideki <hideki.saito at intel.com>; llvm-dev at lists.llvm.org; renato.golin at linaro.org; aemerson at apple.com; mkuper at google.com; mssimpso at codeaurora.org; Simon Moll <moll at cs.uni-saarland.de>; hfinkel at anl.gov > Subject: Re: [llvm-dev] [RFC][LV][VPlan] Proposal for Outer Loop Vectorization Implementation Plan > > One area that needs a bit of attention before work on this proceeds much further is testing.  The introduction of VPlan appears to have introduced a couple of bugs and exposed a couple of others.  Most of those are now fixed, but...

Hi, On 08/02/2018 04:22, Caballero, Diego wrote: > Hi Florian! > > This proposal sounds pretty exciting! Integrating SLP-aware loop vectorization (or the other way around) and SLP into the VPlan framework is definitely aligned with the long term vision and we would prefer this approach to the LoopReroll and InstCombine alternatives that you mentioned. We prefer a generic implementation that can handle complicated cases to something ad-hoc for some simple ones. Because of this, we would hav...

Hi, I noticed that the dead instructions collected when build vplan are invariant to different ranges of VFs since the original loop is not changed. Maybe DeadInstructions should be treated as a data member of LoopVectorizationPlanner and initialized by collectTriviallyDeadInstructions() in plan()? Cheers, Shixiong (Jason) Xu -------------- next part -----------...

Hi Florian! This proposal sounds pretty exciting! Integrating SLP-aware loop vectorization (or the other way around) and SLP into the VPlan framework is definitely aligned with the long term vision and we would prefer this approach to the LoopReroll and InstCombine alternatives that you mentioned. We prefer a generic implementation that can handle complicated cases to something ad-hoc for some simple ones. Because of this, we would hav...

...ales" section below. > > > > A) Preprocessing > > Make a copy of the entire function to allow > transformations only for > > the sake of analysis. > > > > Before we started our journey into VPlan-based vectorization approach, > we explicitly asked about modifying the IR for > > the sake of vectorization analysis ----- general consensus in LLVM-DEV > was "that's a bad idea". We thought so, too. > > That's the reason VPlan has its own local data structure t...

...<hideki.saito at intel.com>; llvm-dev at lists.llvm.org; >> renato.golin at linaro.org; aemerson at apple.com; mkuper at google.com; >> mssimpso at codeaurora.org; Simon Moll <moll at cs.uni-saarland.de>; >> hfinkel at anl.gov >> Subject: Re: [llvm-dev] [RFC][LV][VPlan] Proposal for Outer Loop >> Vectorization Implementation Plan >> >> One area that needs a bit of attention before work on this proceeds >> much further is testing.  The introduction of VPlan appears to have >> introduced a couple of bugs and exposed a couple of others....

...rating on compound values, we propose to extend LoopVectorize to 1. Detect loops containing SLP opportunities (operations on compound values) 2. Extend the cost model to choose between interleaving or using compound values 3. Add support for vectorizing compound operations to VPlan Please note that the example in the previous section is intentionally kept simple and one could argue it could be handled by doing loop rerolling as a canonicalization step before LoopVectorize (currently LoopReroll does not handle this case, but it could be naturally extended to do so). Howev...

...compare it to the original. Moreover, holding multiple, differently > > optimized, copies allows evaluating each variant using a cost function > > and select the 'best' when re-generating LLVM-IR again (or re-use the > > original LLVM-IR). > > This sounds a lot like VPlan. Yes, as mentioned in the Q&A. Unfortunately VPlan is able to represent arbitrary code not has cheap copies. > > Instantiating every possible sequence of transformations of course is > > not feasible, so the search space needs to be pruned. This could be > > made dependent...

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.collectUniformsAndScalars(VF); // Collect the instructions (and their associ...

...alysis of RV) to LLVM. The implementation is available on github for feedback [0]. The existing divergence analysis infrastructure in LLVM has conceptual limitations (structured control, SCEV based). The new analysis resolves bugs for the GPU backends from the first patch on and will be used by VPlan [6] in the mid term. The implementation is based on RV, the Region Vectorizer. -- RV -- The Region Vectorizer (github [1]) is an analysis and transformation framework for outer-loop and whole-function vectorization. RV vectorizes arbitrary, reducible control flow including nested divergent lo...

Hi, I found with the help of the optimization remarks a loop that could not be vectorized, but if loop distribution was enabled this may happen, which it in fact did with a very significant benchmark improvement (~25%). I tried (on SystemZ) to enable this pass, and found that it only affected a handful of files on SPEC. This means I could enable this without worrying about any regressions on

...t;> I'm also going to continue playing around with enhancements to our current dereferenceability logic. I see that as being a key building block to make any predication based approach practical. > This is *always* good work. There has been some work in the past to > common up LV with VPLan analysis stages (separating classes, moving > code), and I think if we keep working on the common infrastructure, > we'll benefit more than just LV or VPlan. > > >> I'm not sure I'm going to get to the predication support. I'd like to, but am not sure my resource...

Jonas/Renato, >I think it's mostly about the success rate, given it's too conservative. But in the past 2 years, improvements in (and around) the LV have been slowed down a bit due to the move >to VPlan. It wasn't our intention to slow down LV improvements, but if the project ended up causing other developers take the stance of wait-and-see, that's an inevitable side effect of any infrastructure level work. We welcome others work with us to move things faster. I hope everyone will see tha...

...for them can be found in the "rationales" section below. A) Preprocessing Make a copy of the entire function to allow transformations only for the sake of analysis. Before we started our journey into VPlan-based vectorization approach, we explicitly asked about modifying the IR for the sake of vectorization analysis ----- general consensus in LLVM-DEV was "that's a bad idea". We thought so, too. That's the reason VPlan has its own local data structure that it can play with. Making...

...hem accordingly. >> >> Mid-end optimisers tend to be fairly agnostic. And when not, they >> usually ask "is this supported" instead of "which one is better". > > Yes, the "is this supported" question is common. Isn't the whole point > of VPlan to get the "which one is better" question answered for > vectorization? That would be necessarily tied to the target. The > questions asked can be agnostic, like the target-agnostics bits of > codegen use, but the answers would be target-specific. Just like the old loop vector...

...a key building block to make any predication based approach practical. I'm not sure I'm going to get to the predication support.  I'd like to, but am not sure my resource constraints allow it.  I'll also mention that I'm not at all sure how all of this might fit in with the VPLAN work.  I'd really welcome feedback on that; is what I'm proposing at all consistent with others plans? Philip -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190909/1da080f1/attachment.html>

Hey folks, Do we have proposals for an HPC focused BoF at EuroLLVM? I'd like to discuss the current efforts around integrating Polly, parallel IR efforts and vectoriser support in VPlan (like outer loop), as well as coordination on the next steps around Flang. -- cheers, --renato