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
----- Original Message -----> From: "Nadav Rotem" <nrotem at apple.com> > To: "llvmdev at cs.uiuc.edu Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Friday, October 5, 2012 1:14:47 AM > 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.Great!> > 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.Having made this suggestion in the past, I am, of course, fully supportive! This is something that we definitely need to do.> 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.We could just call it llvmc (for LLVM compiler). Alternatively, we could add OPTs options to LLC, and add an option to OPT to produce IR output after all of the IR-level passes have completed to emulate the current OPT functionality. Thanks again, Hal> > Thanks, > Nadav > _______________________________________________ > 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
Nadav Rotem wrote:> 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.I absolutely think that we should have something like TargetData (now DataLayout) but for the vector types and operations. However, I'm not familiar with "Target Lowering Interface". Could you explain? 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. This really shouldn't be necessary. Notably, it is still possible today to build a Module and optimize it without having decided what target you're targeting. Nick 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 >
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. - 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
----- 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
Why not just have a hook into the TargetInstrInfo to query for the cost of an instruction? This is already used in many places throughout the optimizers.> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Das, Dibyendu > Sent: Friday, October 05, 2012 2:00 AM > To: Nadav Rotem; llvmdev at cs.uiuc.edu Mailing List > 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. > - 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
I will simply echo Hal here - yes we definitely want to do this, how exactly - let's talk :) Sergei.>> >> 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. >> >Having made this suggestion in the past, I am, of course, fully supportive!This is something that we definitely need to do. --- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation> -----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 1:29 AM > To: Nadav Rotem > Cc: llvmdev at cs.uiuc.edu Mailing List > Subject: Re: [LLVMdev] LLVM Loop Vectorizer > > ----- Original Message ----- > > From: "Nadav Rotem" <nrotem at apple.com> > > To: "llvmdev at cs.uiuc.edu Mailing List" <llvmdev at cs.uiuc.edu> > > Sent: Friday, October 5, 2012 1:14:47 AM > > 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. > > Great! > > > > > 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. > > Having made this suggestion in the past, I am, of course, fully > supportive! This is something that we definitely need to do. > > > 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. > > We could just call it llvmc (for LLVM compiler). Alternatively, we > could add OPTs options to LLC, and add an option to OPT to produce IR > output after all of the IR-level passes have completed to emulate the > current OPT functionality. > > Thanks again, > Hal > > > > > Thanks, > > Nadav > > _______________________________________________ > > 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
On Oct 5, 2012, at 12:08 AM, Nick Lewycky <nicholas at mxc.ca> wrote:> I absolutely think that we should have something like TargetData (now DataLayout) but for the vector types and operations. However, I'm not familiar with "Target Lowering Interface". Could you explain?I agree. Once we make the codegen accessible to the IR-level passes we need to start talking about the right abstraction. I have some ideas, but I wanted to start the discussion after we are done with the first phase. Regarding TLI. So, DAGCombine, CodeGenPrepare, LoopReduce all use the TLI interface which can answer questions such as "is this operation supported ?" or "is this type legal". This is a subset of what we need in a vectorized. We can discuss other requirements that the vectorizer may have after we finish with the first phase. I suspect that we may have to refactor some functionality out of TLI.> > 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. > > This really shouldn't be necessary. Notably, it is still possible today to build a Module and optimize it without having decided what target you're targeting.I agree that it is not necessary for many optimizations. However, this is absolutely needed for lower-level transformations such as strength reduction. So, I plan to keep the current behavior that OPT has where if a target information is not provided through the command line then TargetData is kept uninitialized (null pointer). So, as far as IR-level passes go, nothing is going to change.> > Nick-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121005/cc918739/attachment.html>
>I think that the first step would be to expose Target LoweringInterface (TLI) to OPT's IR-level passes. By "lowering", we assume the bitcode is more abstract than the machine code. However, in some situations, it is just opposite. For instance, some architectures support vectorization of min/max/saturated-{add,sub)/conditional-assignment/etc/../etc. We need to detect such machine dependent patterns, and *PROMOTE* the bitcode into right forms before we are able to vectorize them. How to deal with this situation? Shuxin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121005/af230106/attachment.html>
----- Original Message -----> From: "Shuxin Yang" <shuxin.llvm at gmail.com> > To: "Nadav Rotem" <nrotem at apple.com> > Cc: "llvmdev at cs.uiuc.edu Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Friday, October 5, 2012 12:33:17 PM > Subject: Re: [LLVMdev] LLVM Loop Vectorizer > > > > >I think that the first step would be to expose Target Lowering > >Interface (TLI) to OPT's IR-level passes. > > By "lowering", we assume the bitcode is more abstract than the > machine code. However, in some situations, it is just opposite. For > instance, some architectures support vectorization of > min/max/saturated-{add,sub) / conditional-assignment/etc / ../etc. > We need to detect such machine dependent patterns, and * PROMOTE * > the bitcode into right forms before we are able to vectorize them. > How to deal with this situation?This is a matter of naming. TLI contains information about target capabilities, and could be used to affect the kinds of normalization decisions that you mention. -Hal> > Shuxin > > > _______________________________________________ > 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
I prefer not to drill down into the design of the vectorizer yet, but I think that a cannonicalization phase before the vectorization can handle these cases. On Oct 5, 2012, at 10:33 AM, Shuxin Yang <shuxin.llvm at gmail.com> wrote:> >I think that the first step would be to expose Target Lowering Interface (TLI) to OPT's IR-level passes. > > By "lowering", we assume the bitcode is more abstract than the machine code. However, in some situations, it is just opposite. For instance, some architectures support vectorization of min/max/saturated-{add,sub)/conditional-assignment/etc/../etc. We need to detect such machine dependent patterns, and *PROMOTE* the bitcode into right forms before we are able to vectorize them. How to deal with this situation? > > Shuxin >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121005/beaf93b9/attachment.html>
> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On > Behalf Of Nadav Rotem > > 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.Picking out a different part of Nadav's original email ... are you planning to write yet another loop vectorizer? Do you intend to make it the /the/ LLVM loop vectorizer? Sameer.
On Oct 5, 2012, at 7:23 PM, "Sahasrabuddhe, Sameer" <Sameer.Sahasrabuddhe at amd.com> wrote:> Picking out a different part of Nadav's original email ... are you planning to write yet another loop vectorizer?Is there another loop vectorizer in the open source ? I am not aware of one. If you know of a loop vectorizer that we can use then let me know.> Do you intend to make it the /the/ LLVM loop vectorizer?Yes. Thanks, Nadav -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121005/ef57ac20/attachment.html>