----- Original Message -----> From: "Ramshankar Ramanarayanan" <Ramshankar.Ramanarayanan at amd.com> > To: "Hal Finkel" <hfinkel at anl.gov>, "Dibyendu Das" <Dibyendu.Das at amd.com> > Cc: "llvmdev at cs.uiuc.edu Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Friday, October 5, 2012 11:00:39 AM > Subject: RE: [LLVMdev] LLVM Loop Vectorizer > > Perhaps we can parameterize the size of the vector while vectorizing > @ llvm and fix up the loop iterators in a target specific pass.I don't understand the motivation for your suggestion. Can you please explain? Thanks again, Hal> > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu > [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Hal Finkel > Sent: Friday, October 05, 2012 8:30 PM > To: Das, Dibyendu > Cc: llvmdev at cs.uiuc.edu Mailing List > Subject: Re: [LLVMdev] LLVM Loop Vectorizer > > ----- Original Message ----- > > From: "Dibyendu Das" <Dibyendu.Das at amd.com> > > To: "Nadav Rotem" <nrotem at apple.com>, "llvmdev at cs.uiuc.edu Mailing > > List" <llvmdev at cs.uiuc.edu> > > Sent: Friday, October 5, 2012 3:59:56 AM > > Subject: Re: [LLVMdev] LLVM Loop Vectorizer > > > > I think we should try to abstract the costs of instructions of > > various > > targets instead of trying to replicate them exactly. The coarser > > the > > costing infrastructure the more robust will be the vectorization > > pass. > > Also this eliminates/reduces the need of updating the costing > > infrastructure as and when new h/w reduces the > > cost(s) of existing instructions. > > I think that one of the big questions is where this information, > abstract or not, resides. The cost information needs to be abstract > in some sense: IR instructions don't always map directly onto > machine instructions, we don't yet have real register-pressure > information, etc. Other information is more direct: does the target > support vectors of given types, sizes, and are certain operations > provided. As much as possible, I believe this information should be > derived automatically from the Target TableGen files, and the > pre-existing logic in *ISelLowering.cpp. This requires linking those > files with the mid-level optimizers. > > -Hal > > > - Dibyendu > > > > -----Original Message----- > > From: llvmdev-bounces at cs.uiuc.edu > > [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Nadav Rotem > > Sent: Friday, October 05, 2012 11:45 AM > > To: llvmdev at cs.uiuc.edu Mailing List > > Subject: [LLVMdev] LLVM Loop Vectorizer > > > > Hi, > > > > We are starting to work on an LLVM loop vectorizer. There's number > > of > > different projects that already vectorize LLVM IR. For example > > Hal's > > BB-Vectorizer, Intel's OpenCL Vectorizer, Polly, ISPC, AnySL, just > > to > > name a few. I think that it would be great if we could collaborate > > on > > the areas that are shared between the different projects. I think > > that > > refactoring LLVM in away that would expose target information to > > IR-level transformations would be a good way to start. Vectorizers, > > as > > well as other IR-level transformations, require target-specific > > information, such as the cost of different instruction or the > > availability of certain features. Currently, llvm-based vectorizers > > do > > not make use of this information, or just hard-code target > > information. A loop vectorizer would need target information. After > > we > > have some basic target information infrastructure in place we can > > start discussing the vectorizer itself. > > > > I think that the first step would be to expose Target Lowering > > Interface (TLI) to OPT's IR-level passes. Currently TLI is only > > available in LLC. I suggest that we merge LLC and OPT into a single > > tool that will drive both IR-level passes and the codegen. LLC and > > OPT > > can remain as wrappers around the new tool. Please let me know if > > you > > can think of a good name for the new tool. I was thinking that > > "llvm-cli" may be a good name (cli = command line interface). > > OPT and LLC are only used by LLVM developers, so the impact of this > > change on the user community would be small. > > > > Thanks, > > Nadav > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > > > > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > -- > Hal Finkel > Postdoctoral Appointee > Leadership Computing Facility > Argonne National Laboratory > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > >-- Hal Finkel Postdoctoral Appointee Leadership Computing Facility Argonne National Laboratory
If -simd option is specified opt could do validity checks, dependency analysis and such and recognize that a loop can be executed in parallel and as the -simd option is specified, convert the data types to vector instructions and add the scaling factor to the loop's iterators. Following this there can be an early machine function pass that sets up processor specific value in all of instructions in a loop vectorized by opt. This pass could look over options to see what is expected by the user and what is set to default etc. for example for newest x86-64 there is an option -mprefer-avx128 for gcc, which helps over 256AVX for several cases. The generic vector types in llvm could be put to use in opt. -----Original Message----- From: Hal Finkel [mailto:hfinkel at anl.gov] Sent: Friday, October 05, 2012 9:39 PM To: Ramanarayanan, Ramshankar Cc: llvmdev at cs.uiuc.edu Mailing List; Das, Dibyendu Subject: Re: [LLVMdev] LLVM Loop Vectorizer ----- Original Message -----> From: "Ramshankar Ramanarayanan" <Ramshankar.Ramanarayanan at amd.com> > To: "Hal Finkel" <hfinkel at anl.gov>, "Dibyendu Das" > <Dibyendu.Das at amd.com> > Cc: "llvmdev at cs.uiuc.edu Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Friday, October 5, 2012 11:00:39 AM > Subject: RE: [LLVMdev] LLVM Loop Vectorizer > > Perhaps we can parameterize the size of the vector while vectorizing @ > llvm and fix up the loop iterators in a target specific pass.I don't understand the motivation for your suggestion. Can you please explain? Thanks again, Hal> > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu > [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Hal Finkel > Sent: Friday, October 05, 2012 8:30 PM > To: Das, Dibyendu > Cc: llvmdev at cs.uiuc.edu Mailing List > Subject: Re: [LLVMdev] LLVM Loop Vectorizer > > ----- Original Message ----- > > From: "Dibyendu Das" <Dibyendu.Das at amd.com> > > To: "Nadav Rotem" <nrotem at apple.com>, "llvmdev at cs.uiuc.edu Mailing > > List" <llvmdev at cs.uiuc.edu> > > Sent: Friday, October 5, 2012 3:59:56 AM > > Subject: Re: [LLVMdev] LLVM Loop Vectorizer > > > > I think we should try to abstract the costs of instructions of > > various targets instead of trying to replicate them exactly. The > > coarser the costing infrastructure the more robust will be the > > vectorization pass. > > Also this eliminates/reduces the need of updating the costing > > infrastructure as and when new h/w reduces the > > cost(s) of existing instructions. > > I think that one of the big questions is where this information, > abstract or not, resides. The cost information needs to be abstract in > some sense: IR instructions don't always map directly onto machine > instructions, we don't yet have real register-pressure information, > etc. Other information is more direct: does the target support vectors > of given types, sizes, and are certain operations provided. As much as > possible, I believe this information should be derived automatically > from the Target TableGen files, and the pre-existing logic in > *ISelLowering.cpp. This requires linking those files with the > mid-level optimizers. > > -Hal > > > - Dibyendu > > > > -----Original Message----- > > From: llvmdev-bounces at cs.uiuc.edu > > [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Nadav Rotem > > Sent: Friday, October 05, 2012 11:45 AM > > To: llvmdev at cs.uiuc.edu Mailing List > > Subject: [LLVMdev] LLVM Loop Vectorizer > > > > Hi, > > > > We are starting to work on an LLVM loop vectorizer. There's number > > of different projects that already vectorize LLVM IR. For example > > Hal's BB-Vectorizer, Intel's OpenCL Vectorizer, Polly, ISPC, AnySL, > > just to name a few. I think that it would be great if we could > > collaborate on the areas that are shared between the different > > projects. I think that refactoring LLVM in away that would expose > > target information to IR-level transformations would be a good way > > to start. Vectorizers, as well as other IR-level transformations, > > require target-specific information, such as the cost of different > > instruction or the availability of certain features. Currently, > > llvm-based vectorizers do not make use of this information, or just > > hard-code target information. A loop vectorizer would need target > > information. After we have some basic target information > > infrastructure in place we can start discussing the vectorizer > > itself. > > > > I think that the first step would be to expose Target Lowering > > Interface (TLI) to OPT's IR-level passes. Currently TLI is only > > available in LLC. I suggest that we merge LLC and OPT into a single > > tool that will drive both IR-level passes and the codegen. LLC and > > OPT can remain as wrappers around the new tool. Please let me know > > if you can think of a good name for the new tool. I was thinking > > that "llvm-cli" may be a good name (cli = command line interface). > > OPT and LLC are only used by LLVM developers, so the impact of this > > change on the user community would be small. > > > > Thanks, > > Nadav > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > > > > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > -- > Hal Finkel > Postdoctoral Appointee > Leadership Computing Facility > Argonne National Laboratory > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > >-- Hal Finkel Postdoctoral Appointee Leadership Computing Facility Argonne National Laboratory
----- Original Message -----> From: "Ramshankar Ramanarayanan" <Ramshankar.Ramanarayanan at amd.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "llvmdev at cs.uiuc.edu Mailing List" <llvmdev at cs.uiuc.edu>, "Dibyendu Das" <Dibyendu.Das at amd.com> > Sent: Friday, October 5, 2012 11:42:48 AM > Subject: RE: [LLVMdev] LLVM Loop Vectorizer > > If -simd option is specified opt could do validity checks, dependency > analysis and such and recognize that a loop can be executed in > parallel and as the -simd option is specified, convert the data > types to vector instructions and add the scaling factor to the > loop's iterators. Following this there can be an early machine > function pass that sets up processor specific value in all of > instructions in a loop vectorized by opt. This pass could look over > options to see what is expected by the user and what is set to > default etc.Do you mean having this later pass choose the blocking factors, etc?> for example for newest x86-64 there is an option > -mprefer-avx128 for gcc, which helps over 256AVX for several cases. > The generic vector types in llvm could be put to use in opt.I think that, where possible, the idea is to retain the use of the generic LLVM vector types. Target-specific knowledge, however, might be used to decide when to form those types and with what operations to use them. -Hal> > -----Original Message----- > From: Hal Finkel [mailto:hfinkel at anl.gov] > Sent: Friday, October 05, 2012 9:39 PM > To: Ramanarayanan, Ramshankar > Cc: llvmdev at cs.uiuc.edu Mailing List; Das, Dibyendu > Subject: Re: [LLVMdev] LLVM Loop Vectorizer > > > > ----- Original Message ----- > > From: "Ramshankar Ramanarayanan" <Ramshankar.Ramanarayanan at amd.com> > > To: "Hal Finkel" <hfinkel at anl.gov>, "Dibyendu Das" > > <Dibyendu.Das at amd.com> > > Cc: "llvmdev at cs.uiuc.edu Mailing List" <llvmdev at cs.uiuc.edu> > > Sent: Friday, October 5, 2012 11:00:39 AM > > Subject: RE: [LLVMdev] LLVM Loop Vectorizer > > > > Perhaps we can parameterize the size of the vector while > > vectorizing @ > > llvm and fix up the loop iterators in a target specific pass. > > I don't understand the motivation for your suggestion. Can you please > explain? > > Thanks again, > Hal > > > > > -----Original Message----- > > From: llvmdev-bounces at cs.uiuc.edu > > [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Hal Finkel > > Sent: Friday, October 05, 2012 8:30 PM > > To: Das, Dibyendu > > Cc: llvmdev at cs.uiuc.edu Mailing List > > Subject: Re: [LLVMdev] LLVM Loop Vectorizer > > > > ----- Original Message ----- > > > From: "Dibyendu Das" <Dibyendu.Das at amd.com> > > > To: "Nadav Rotem" <nrotem at apple.com>, "llvmdev at cs.uiuc.edu > > > Mailing > > > List" <llvmdev at cs.uiuc.edu> > > > Sent: Friday, October 5, 2012 3:59:56 AM > > > Subject: Re: [LLVMdev] LLVM Loop Vectorizer > > > > > > I think we should try to abstract the costs of instructions of > > > various targets instead of trying to replicate them exactly. The > > > coarser the costing infrastructure the more robust will be the > > > vectorization pass. > > > Also this eliminates/reduces the need of updating the costing > > > infrastructure as and when new h/w reduces the > > > cost(s) of existing instructions. > > > > I think that one of the big questions is where this information, > > abstract or not, resides. The cost information needs to be abstract > > in > > some sense: IR instructions don't always map directly onto machine > > instructions, we don't yet have real register-pressure information, > > etc. Other information is more direct: does the target support > > vectors > > of given types, sizes, and are certain operations provided. As much > > as > > possible, I believe this information should be derived > > automatically > > from the Target TableGen files, and the pre-existing logic in > > *ISelLowering.cpp. This requires linking those files with the > > mid-level optimizers. > > > > -Hal > > > > > - Dibyendu > > > > > > -----Original Message----- > > > From: llvmdev-bounces at cs.uiuc.edu > > > [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Nadav Rotem > > > Sent: Friday, October 05, 2012 11:45 AM > > > To: llvmdev at cs.uiuc.edu Mailing List > > > Subject: [LLVMdev] LLVM Loop Vectorizer > > > > > > Hi, > > > > > > We are starting to work on an LLVM loop vectorizer. There's > > > number > > > of different projects that already vectorize LLVM IR. For example > > > Hal's BB-Vectorizer, Intel's OpenCL Vectorizer, Polly, ISPC, > > > AnySL, > > > just to name a few. I think that it would be great if we could > > > collaborate on the areas that are shared between the different > > > projects. I think that refactoring LLVM in away that would expose > > > target information to IR-level transformations would be a good > > > way > > > to start. Vectorizers, as well as other IR-level transformations, > > > require target-specific information, such as the cost of > > > different > > > instruction or the availability of certain features. Currently, > > > llvm-based vectorizers do not make use of this information, or > > > just > > > hard-code target information. A loop vectorizer would need target > > > information. After we have some basic target information > > > infrastructure in place we can start discussing the vectorizer > > > itself. > > > > > > I think that the first step would be to expose Target Lowering > > > Interface (TLI) to OPT's IR-level passes. Currently TLI is only > > > available in LLC. I suggest that we merge LLC and OPT into a > > > single > > > tool that will drive both IR-level passes and the codegen. LLC > > > and > > > OPT can remain as wrappers around the new tool. Please let me > > > know > > > if you can think of a good name for the new tool. I was thinking > > > that "llvm-cli" may be a good name (cli = command line > > > interface). > > > OPT and LLC are only used by LLVM developers, so the impact of > > > this > > > change on the user community would be small. > > > > > > Thanks, > > > Nadav > > > _______________________________________________ > > > LLVM Developers mailing list > > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > > > > > > > > > _______________________________________________ > > > LLVM Developers mailing list > > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > > > > -- > > Hal Finkel > > Postdoctoral Appointee > > Leadership Computing Facility > > Argonne National Laboratory > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > > > > > -- > Hal Finkel > Postdoctoral Appointee > Leadership Computing Facility > Argonne National Laboratory > >-- Hal Finkel Postdoctoral Appointee Leadership Computing Facility Argonne National Laboratory