search for: islegalmask

...fo. > Eventually, I'd like to see these under Analysis subtree (instead of Transform), since they are indeed Analysis. > > As a first step of this LoopVectorizationLegality cleanup, I propose to move the following checks > (and member functions) to LoopVectorizationCostModel. > isLegalMaskedStore > isLegalMaskedLoad > isLegalMaskedScatter > isLegalMaskedGather > My assumption is that all SIMD architectures should support serialization of those operations > at some cost (e.g., lowering in CG prepare) and thus failing to vectorize due to "false" return valu...

...Diego <diego.caballero at intel.com>; Sanjay Patel <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 &g...

...ero, Diego <diego.caballero at intel.com>; Sanjay Patel <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 w...

...opVectorizationAnalysisInfo. Eventually, I'd like to see these under Analysis subtree (instead of Transform), since they are indeed Analysis. As a first step of this LoopVectorizationLegality cleanup, I propose to move the following checks (and member functions) to LoopVectorizationCostModel. isLegalMaskedStore isLegalMaskedLoad isLegalMaskedScatter isLegalMaskedGather My assumption is that all SIMD architectures should support serialization of those operations at some cost (e.g., lowering in CG prepare) and thus failing to vectorize due to "false" return values of those calls is in...

...ero, Diego <diego.caballero at intel.com>; Sanjay Patel <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...

On 17 March 2017 at 16:34, Hal Finkel <hfinkel at anl.gov> wrote: > In general, this is true everywhere. In a large vectorized loop, this cost > may well be worthwhile. The idea is that the cost model should account for > all of these costs. If it doesn't properly, we should fix that. Isn't this only worth when the SIMD instructions can be conditionalised per lane? I

...9; version. He observes that incrementing the major version immediately upon branching means it's difficult to write reliable checks such as `#if __clang_major__ >= 7`. * Hideki Saito is [looking](http://lists.llvm.org/pipermail/llvm-dev/2018-January/120164.html) for feedback on moving the `isLegalMasked*` checks to LoopVectorizationCostModel. * Nemanja Ivanovic is [seeking feedback](http://lists.llvm.org/pipermail/llvm-dev/2018-January/120171.html) on legalizing the input operand to `ATOMIC_CMP_SWAP*` by zero-extending. * Alex Bradbury has outlined the current in-tree uses of custom CCState an...