search for: vpinstructions

>I think we need to get that story right for both cases up front. Renato, I kicked off this secondary discussion, borrowing the opportunity from Michael's RFC, but to the point of reviewing https://reviews.llvm.org/D38676, I'd like the review to proceed separately from this bigger (and most likely longer) discussion. We intentionally made the interfaces similar such that whatever the

>Do you recall the arguments why it was considered a bad idea? Felt like long time ago, but it turned out that was actually just a bit over a year ago. Here's the thread. http://lists.llvm.org/pipermail/llvm-dev/2016-August/104079.html Only a few explicitly responded, but I took that as silent majority was satisfied with the responses. Prior to that thread, I also pinged HPC oriented LLVM

...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 prop...

...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 interleave m...

...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 prop...

Michael, [Sorry that I don't have you in To:. I don't have your addr that I can use since I'm replying through digest.] 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. Proposed Loop Optimization Framework ------------------------------------

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

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. > > > >

...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 seri...

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 acces...

...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 inte...

...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 the...

...>>        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 r...

...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 als...

...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 als...