similar to: [VPlan] about vectorization factor selection

Displaying 20 results from an estimated 200 matches similar to: "[VPlan] about vectorization factor selection"

2018 Jun 01
2
[VPlan] Dead instructions are invariant to VFs when build vplan
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 -------------- An HTML attachment was
2013 Jan 28
0
[LLVMdev] Floats as Doubles in Vectors
Hi Hal, I am not familiar with Blue Gene at all but I will do my best to answer. > is going to assume that the vectors can hold 256/32 == 8 single-precision values even though the real maximum is 4 values. How should we handle this? The loop vectorizer uses TTI to find the size of the vector register. It uses this number to calculate the maximum vectorization factor. The formula is MaxVF =
2016 Aug 18
2
Cost model is missing in InstCombiner
----- Original Message ----- > From: "Mehdi Amini via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Shixiong Xu" <shixiong at cadence.com> > Cc: llvm-dev at lists.llvm.org > Sent: Thursday, August 18, 2016 11:05:35 AM > Subject: Re: [llvm-dev] Cost model is missing in InstCombiner > +David M. > > On Aug 17, 2016, at 3:48 AM, Shixiong Xu
2016 Aug 17
2
Cost model is missing in InstCombiner
Hi, I think canEvaluateTruncated() in InstCombiner needs use cost model to decide whether perform optimization or not. Without cost model from TargetTransformInfo, aggressively optimizing IR in vector types according to the number of bits demanded may lead to scalarization of vector operations. For example, if the input IR is: %wide.load25 = load <32 x i8>, <32 x i8>* %231, align
2013 Jan 27
3
[LLVMdev] Floats as Doubles in Vectors
Nadav, et al., On the BG/Q, the vectors hold 4 double-precision values. For vectorizing single-precision code, there are single-precision-rounded instructions, and special load/store instructions, which allow the double-precision numbers to be treated as single-precision numbers. The problem is that the current vectorization code (in the BBVectorizer and, as far as I can tell, also in the
2017 Dec 06
5
[LV][VPlan] Status Update on VPlan ----- where we are currently, and what's ahead of us
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 progress and the future steps needed.   Background: ----------- This is related to
2018 Jan 16
1
[RFC][LV][VPlan] Proposal for Outer Loop Vectorization Implementation Plan
On 01/15/2018 03:52 PM, Philip Reames wrote: > To revive the discussion around vectorizer testing, here's a quick > sample of a few of the issues hit recently in the loop vectorizer.  I > want to be careful to say that I am not stating these are the result > of any recent work, just that they're issues that have been triaged > down to the loop vectorizer doing something
2013 Jan 03
1
[LLVMdev] Does loop vectorizer inquire about target's SIMD capabilities?
Hi Nadav, On Thu, Jan 3, 2013 at 1:53 PM, Nadav Rotem <nrotem at apple.com> wrote: > Hi Akira! > > > > > Does the current loop vectorizer inquire about the SIMD capabilities of > the target architecture when it decides whether it is profitable to > vectorize a loop? > > Yes, it uses a cost model to determine the profitability of vectorization. > At the
2013 Jan 28
2
[LLVMdev] Floats as Doubles in Vectors
----- Original Message ----- > From: "Nadav Rotem" <nrotem at apple.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Sunday, January 27, 2013 9:16:42 PM > Subject: Re: Floats as Doubles in Vectors > > Hi Hal, > > I am not familiar with Blue Gene at all but
2018 Jan 15
0
[RFC][LV][VPlan] Proposal for Outer Loop Vectorization Implementation Plan
To revive the discussion around vectorizer testing, here's a quick sample of a few of the issues hit recently in the loop vectorizer.  I want to be careful to say that I am not stating these are the result of any recent work, just that they're issues that have been triaged down to the loop vectorizer doing something incorrect or questionable from a performance perspective.
2017 Dec 06
3
[RFC][LV][VPlan] Proposal for Outer Loop Vectorization Implementation Plan
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   ===========
2017 Dec 14
3
[RFC][LV][VPlan] Proposal for Outer Loop Vectorization Implementation Plan
>Another might be to introduce changes under feature flags to ease the revert/reintroduce/revert cycle. This is essentially the first guard. We plan to have flags/settings to control which types of outer loops are handled. The new code path is initially exclusive to outer loop vectorization. If we disable all types of outer loops (and that's the initial default), LV continues to be good
2013 Jan 03
0
[LLVMdev] Does loop vectorizer inquire about target's SIMD capabilities?
Hi Akira! > > Does the current loop vectorizer inquire about the SIMD capabilities of the target architecture when it decides whether it is profitable to vectorize a loop? Yes, it uses a cost model to determine the profitability of vectorization. At the moment only x86 provides the necessary hooks that are needed for calculating the costs. We may need to change the cost defaults to
2017 Feb 27
4
[Proposal][RFC] Epilog loop vectorization
Thanks for looking into this. 1) Issues with re running vectorizer: Vectorizer might generate redundant alias checks while vectorizing epilog loop. Redundant alias checks are expensive, we like to reuse the results of already computed alias checks. With metadata we can limit the width of epilog loop, but not sure about reusing alias check result. Any thoughts on rerunning vectorizer with reusing
2013 Jan 03
3
[LLVMdev] Does loop vectorizer inquire about target's SIMD capabilities?
Nadav (or anyone who is familiar with the loop vectorizer), Does the current loop vectorizer inquire about the SIMD capabilities of the target architecture when it decides whether it is profitable to vectorize a loop? I am asking this because I would like to have loop vectorization disabled for targets that don't support SIMD instructions (for example, standard mips32). Loop vectorization
2020 Nov 17
0
[Proposal] Introducing the concept of invalid costs to the IR cost model
It might also make sense to have functions that return costs for vector ops return some sort of `LinearPolyBase` with `ScalarTy` being `InstructionCost`. From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Vineet Kumar via llvm-dev Sent: Monday, November 16, 2020 11:24 PM To: David Sherwood <David.Sherwood at arm.com>; llvm-dev at lists.llvm.org Subject: [EXT] Re:
2020 Nov 05
4
[Proposal] Introducing the concept of invalid costs to the IR cost model
Hi, I'd like to propose a change to our cost interfaces so that instead of returning an unsigned value from functions like getInstructionCost, getUserCost, etc., we instead return a wrapper class that encodes an integer cost along with extra state. The extra state can be used to express: 1. A cost as infinitely expensive in order to prevent certain optimisations taking place. For example,
2018 Feb 08
2
[RFC] Make LoopVectorize Aware of SLP Operations
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
2018 Feb 08
0
[RFC] Make LoopVectorize Aware of SLP Operations
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
2017 Oct 14
3
[RFC] Polly Status and Integration
On Fri, Oct 13, 2017 at 5:13 PM, Michael Kruse via llvm-dev < llvm-dev at lists.llvm.org> wrote: > 2017-10-14 1:29 GMT+02:00 Saito, Hideki via llvm-dev < > llvm-dev at lists.llvm.org>: > > I'm also sorry that I'm not commenting on the main part of your RFC in > this reply. I just want to focus on > > one thing here. > > > >