search for: vpinstruct

...review to proceed separately from this bigger (and most likely longer) discussion. We intentionally made the interfaces similar such that whatever the outcome of this discussion would be, the changes we have to make later, if any, is small and mechanical. We just need to agree that VPValue/VPUser/VPInstruction is not a precedence, i.e., still subject to ongoing discussion and is expected to abide by the eventual outcome of this discussion. To the best of my understanding, if we do not want to modify the IR (i.e., CFG, Instructions, and Uses/Defs hooked up in the Function) before we decide to let vect...

...s that already exist and have matured. I agree. So, I dream about a lighter weight version of Value class hierarchy where many of the standard Value class hierarchy algorithm can run, without making lighter weight stuff hooked into the actual IR state. We intentionally tried to make VPValue/VPUser/VPInstruction interfaces "subset of" Value/User/Instruction interfaces such that the code sharing (not copying/pasting) can be possible. This is practical enough so far, but I'm still wondering, in a long run, whether we can do something better. Thus, constructive ideas are welcome. Thanks, Hid...

...modular implementation of cost-modelling. > > >> Add support for SLP style vectorization to Vplan >> ------------------------------------------------------------------------ >> Introduce 2 new recipes VPSLPMemoryRecipe and VPSLPInstructionRecipe. > > We introduced VPInstructions to model masking in patch D38676. They are necessary to properly model the def-use/use-def chains in the VPlan representation, and we believe you will need to represent def-use/use-def chains for newly inserted operations, shuffles, and inserts/extracts. As such, VPInstructions would be a more...

...VPlan to model the vectorized code and drive its transformation)      Has been broken down to a series of smaller patches and went in. The last (re)commit of the series is      https://reviews.llvm.org/rL311849 https://reviews.llvm.org/D38676 by Gil Rapaport. (Modeling masking in VPlan, introducing VPInstructions)      This is also being broken down to a series of smaller patches to facilitate the review.      Committed as https://reviews.llvm.org/rL318645   Where We Are: ------------- With the first patch, we introduced the concept of VPlan to LV and started explicitly recording decisions like interlea...

...ctorization scenarios in the future. This seems to fit into that category. > Add support for SLP style vectorization to Vplan > ------------------------------------------------------------------------ > Introduce 2 new recipes VPSLPMemoryRecipe and VPSLPInstructionRecipe. We introduced VPInstructions to model masking in patch D38676. They are necessary to properly model the def-use/use-def chains in the VPlan representation, and we believe you will need to represent def-use/use-def chains for newly inserted operations, shuffles, and inserts/extracts. As such, VPInstructions would be a more...

...unlikely that you'll get overwhelming support on "copy the entire function" before the decision to transform is taken. So, if this part is optional, you may want to state that. Having said that, in https://reviews.llvm.org/D38676, we are introducing concepts like VPValue, VPUser, and VPInstruction, in order to manipulate and interact with things that didn't come from the IR of the original loop (nest). As such, I can see why you think "a playground copy of IR" is beneficial. Even before reading your RFC, I was actually thinking that someone else may also benefit from VPValue...

Hello, We would like to propose making LoopVectorize aware of SLP operations, to improve the generated code for loops operating on struct fields or doing complex math. At the moment, LoopVectorize uses interleaving to vectorize loops that operate on values loaded/stored from consecutive addresses: vector loads/stores are generated to combine consecutive loads/stores and then shufflevector

...t; support on "copy the entire function" before the decision > > to transform is taken. So, if this part is optional, you may want to > state that. > > > > Having said that, in https://reviews.llvm.org/D38676, we are > introducing concepts like VPValue, VPUser, and VPInstruction, > > in order to manipulate and interact with things that didn't come from > the IR of the original loop (nest). As such, I can see > > why you think "a playground copy of IR" is beneficial. Even before > reading your RFC, I was actually thinking that someone >...

...VPlan to model the vectorized code and drive its transformation)      Has been broken down to a series of smaller patches and went in. The last (re)commit of the series is      https://reviews.llvm.org/rL311849 https://reviews.llvm.org/D38676 by Gil Rapaport. (Modeling masking in VPlan, introducing VPInstructions)      This is also broken down to a series of smaller patches to facilitate the review.      Committed as https://reviews.llvm.org/rL318645   With the first patch, we introduced the concept of VPlan to LV and started explicitly recording decisions like interleave memory access optimization and...

On 10/14/2017 05:28 PM, Daniel Berlin via llvm-dev wrote: > > > On Sat, Oct 14, 2017 at 2:54 PM, Michael Kruse <llvmdev at meinersbur.de > <mailto:llvmdev at meinersbur.de>> wrote: > > 2017-10-14 5:03 GMT+02:00 Daniel Berlin <dberlin at dberlin.org > <mailto:dberlin at dberlin.org>>: > > FWIW: We hit a subset of this issue with

...code and drive its transformation) >      Has been broken down to a series of smaller patches and went in. > The last (re)commit of the series is >      https://reviews.llvm.org/rL311849 > https://reviews.llvm.org/D38676 by Gil Rapaport. (Modeling masking in > VPlan, introducing VPInstructions) >      This is also broken down to a series of smaller patches to facilitate the review. >      Committed as https://reviews.llvm.org/rL318645 > > With the first patch, we introduced the concept of VPlan to LV and started explicitly recording decisions like interleave memory a...

...transformation) >>      Has been broken down to a series of smaller patches and went in. >> The last (re)commit of the series is >>      https://reviews.llvm.org/rL311849 >> https://reviews.llvm.org/D38676 by Gil Rapaport. (Modeling masking in >> VPlan, introducing VPInstructions) >>      This is also broken down to a series of smaller patches to facilitate the review. >>      Committed as https://reviews.llvm.org/rL318645 >> >> With the first patch, we introduced the concept of VPlan to LV and started explicitly recording decisions like...

...ontrolled by > the RISC-V `vsetvli` instruction and using Vector Predicated intrinsics > (https://reviews.llvm.org/D57504). (Of course, intrinsics come with > their own limitations but we feel it serves as a good proof of concept > for our use case.) We also extend the VPlan to generate VPInstructions > that are expanded using predicated intrinsics. > > We also considered a third hybrid approach of having a vector loop with > VF = whole register width, followed by a vector tail loop using > predicated intrinsics. For now though, based on project requirements, > we favoured...

...>>        Has been broken down to a series of smaller patches and went in. >>> The last (re)commit of the series is >>>        https://reviews.llvm.org/rL311849 >>> https://reviews.llvm.org/D38676 by Gil Rapaport. (Modeling masking in >>> VPlan, introducing VPInstructions) >>>        This is also broken down to a series of smaller patches to >>> facilitate the review. >>>        Committed as https://reviews.llvm.org/rL318645 >>>    With the first patch, we introduced the concept of VPlan to LV >>> and started explicit...

...tive vector length controlled by the RISC-V `vsetvli` instruction and using Vector Predicated intrinsics (https://reviews.llvm.org/D57504). (Of course, intrinsics come with their own limitations but we feel it serves as a good proof of concept for our use case.) We also extend the VPlan to generate VPInstructions that are expanded using predicated intrinsics. We also considered a third hybrid approach of having a vector loop with VF = whole register width, followed by a vector tail loop using predicated intrinsics. For now though, based on project requirements, we favoured the second approach. We have...

...tive vector length controlled by the RISC-V `vsetvli` instruction and using Vector Predicated intrinsics (https://reviews.llvm.org/D57504). (Of course, intrinsics come with their own limitations but we feel it serves as a good proof of concept for our use case.) We also extend the VPlan to generate VPInstructions that are expanded using predicated intrinsics. We also considered a third hybrid approach of having a vector loop with VF = whole register width, followed by a vector tail loop using predicated intrinsics. For now though, based on project requirements, we favoured the second approach. We have...