On 11/21/2012 11:32 AM, Tobias Grosser wrote:> On 11/21/2012 03:45 PM, Krzysztof Parzyszek wrote: >> >> I'm thinking of this in terms of parallelization directives. The >> optimizations that rely on such annotations would need to be done as >> early as possible, before any optimization that could invalidate them. >> If the annotation can become false, you are right---it's probably not a >> good idea to have it as the medium. > > If we use metadata to model annotations, we need to ensure that it is > either correct or in case a transformation can not guarantee the > correctness of the meta data, that it is removed.Yes, that is not hard to accomplish.>> Other types of annotations that are >> "harmless" are probably good to have, for example "unroll-by" (assuming >> that this is a suggestion to the compiler, not an order). > > To my knowledge, we are avoiding to allow the user to 'tune' the > compiler. Manual tuning may be good for a certain piece of hardware, but > will have negative effects on other platforms.A lot of ISV code is meant to run on a particular platform, or on a small set of target platforms. Such code is often hand-tuned and the tuning directives will be different for different targets.. I see no reason why we shouldn't allow that. As a matter of fact, not allowing it will make us less competitive.> Instead of providing facilities to tune the hardware, we should > understand why LLVM does not choose the right unrolling factor.Because in general it's impossible. User's hints are always welcome. -Krzysztof -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
On 11/21/2012 06:56 PM, Krzysztof Parzyszek wrote:> On 11/21/2012 11:32 AM, Tobias Grosser wrote: >> On 11/21/2012 03:45 PM, Krzysztof Parzyszek wrote: >>> >>> I'm thinking of this in terms of parallelization directives. The >>> optimizations that rely on such annotations would need to be done as >>> early as possible, before any optimization that could invalidate them. >>> If the annotation can become false, you are right---it's probably not a >>> good idea to have it as the medium. >> >> If we use metadata to model annotations, we need to ensure that it is >> either correct or in case a transformation can not guarantee the >> correctness of the meta data, that it is removed. > > Yes, that is not hard to accomplish.Actually, I believe this is _not_ easy. Though, it makes only sense to discuss this with a specific annotation in mind.>>> Other types of annotations that are >>> "harmless" are probably good to have, for example "unroll-by" (assuming >>> that this is a suggestion to the compiler, not an order). >> >> To my knowledge, we are avoiding to allow the user to 'tune' the >> compiler. Manual tuning may be good for a certain piece of hardware, but >> will have negative effects on other platforms. > > A lot of ISV code is meant to run on a particular platform, or on a > small set of target platforms. Such code is often hand-tuned and the > tuning directives will be different for different targets.. I see no > reason why we shouldn't allow that. As a matter of fact, not allowing > it will make us less competitive.This was the impression I got. Feel free to show examples/patches that convince people to push this. Cheers Tobi
On 11/21/2012 12:48 PM, Tobias Grosser wrote:> On 11/21/2012 06:56 PM, Krzysztof Parzyszek wrote: >> >> Yes, that is not hard to accomplish. > > Actually, I believe this is _not_ easy. Though, it makes only sense to > discuss this with a specific annotation in mind.Agreed. If there is a dedicated consumer of certain annotations, then after it's done, it should remove the annotations. This is not hard when it can run early enough not to have the annotations altered by prior transformations. Now, if there are special annotations for several dedicated consumers, or the consumer has to run late, then it does become difficult. What would be nice is if we came up with a design that would allow a relatively easy validation of the annotations (something conceptually similar to error-detecting codes). The consumer then would disregard and remove the annotations that are no longer valid. -Krzysztof -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
I am thinking about another use of annotations that fits in a longer term vision, which centers around feeding compilers with information from higher-level tools such as precompilers. Deciding how to map a portable piece of software to a heterogeneous multicore processor and get the best performance for a range of widely varying architectures, requires much higher level code analysis than what is possible in "standard" compilers on their relatively low-level IRs. To have portable performance and high programmer productivity, an application will need to be written in a higher-level language, like Julia, MATLAB, ... that can deliver much of the needed information to the compilers, for example by using parallel programming patterns (see Berkeley Parlab), and that allows a compiler to choose among different implementations of algorithms and data structures (see Petabricks). Building compiler front-ends, middle-ends and back-ends from scratch that can use all information available in such programs and that produce high-quality code for a range of architectures is undoable for most if not all research labs. And it should also not be necessary: many excellent lower-level language compilers already exist, some of which support a wide range of architectures, such as LLVM (OoO CPUs, VLIWs, GPUs, CGRAs in my own backend and in Samsung's proprietary SRP backend, etc.). So for research purposes and hopefully later also real-world development if the research results are good, ideally we would have to only develop the necessary precompiler tools that take in very high-level code and that produce tuned lower-level (C or bitcode or LLVM IR or ...) after high-level analysis and target-dependent optimisations and selections, after which LLVM then takes care of the further low-level optimizations and specific code generation for the different targets in the heterogeneous multicore. To facilitate research in this direction and use LLVM in such a tool flow, it is absolutely necessary that both the precompiler and the researcher doing manual experiments can steer the low-level LLVM compiler with code annotations such as loop pragmas or attributes, simply because once the code is in a lower-level form such as C or bitcode or LLVM IR, there is not enough information available in the code itself to select the best low-level transformations. It is interesting to note that in such an approach, the precompiler probably would be trained with machine learning. If this is the case, it might also be able to learn which annotations actually influence the compiler and which do not, for example because they are destroyed before some optimization pass is executed. So the precompiler can learn to generate code tuned for specific targets taking into account all limitations of the compiler that will do the actual code generation, including its incomplete or stupid or whatever support for pragmas and other such things... Best, Bjorn On 21 Nov 2012, at 18:56, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote:> On 11/21/2012 11:32 AM, Tobias Grosser wrote: >> On 11/21/2012 03:45 PM, Krzysztof Parzyszek wrote: >>> >>> I'm thinking of this in terms of parallelization directives. The >>> optimizations that rely on such annotations would need to be done as >>> early as possible, before any optimization that could invalidate them. >>> If the annotation can become false, you are right---it's probably not a >>> good idea to have it as the medium. >> >> If we use metadata to model annotations, we need to ensure that it is >> either correct or in case a transformation can not guarantee the >> correctness of the meta data, that it is removed. > > Yes, that is not hard to accomplish. > > >>> Other types of annotations that are >>> "harmless" are probably good to have, for example "unroll-by" (assuming >>> that this is a suggestion to the compiler, not an order). >> >> To my knowledge, we are avoiding to allow the user to 'tune' the >> compiler. Manual tuning may be good for a certain piece of hardware, but >> will have negative effects on other platforms. > > A lot of ISV code is meant to run on a particular platform, or on a small set of target platforms. Such code is often hand-tuned and the tuning directives will be different for different targets.. I see no reason why we shouldn't allow that. As a matter of fact, not allowing it will make us less competitive. > > >> Instead of providing facilities to tune the hardware, we should >> understand why LLVM does not choose the right unrolling factor. > > Because in general it's impossible. User's hints are always welcome. > > -Krzysztof > > > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation > _______________________________________________ > 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: "Bjorn De Sutter" <bjorn.desutter at elis.ugent.be> > To: llvmdev at cs.uiuc.edu > Sent: Tuesday, November 27, 2012 6:49:39 AM > Subject: Re: [LLVMdev] loop pragmas > > I am thinking about another use of annotations that fits in a longer > term vision, which centers around feeding compilers with information > from higher-level tools such as precompilers. > > Deciding how to map a portable piece of software to a heterogeneous > multicore processor and get the best performance for a range of > widely varying architectures, requires much higher level code > analysis than what is possible in "standard" compilers on their > relatively low-level IRs. To have portable performance and high > programmer productivity, an application will need to be written in a > higher-level language, like Julia, MATLAB, ... that can deliver much > of the needed information to the compilers, for example by using > parallel programming patterns (see Berkeley Parlab), and that allows > a compiler to choose among different implementations of algorithms > and data structures (see Petabricks). Building compiler front-ends, > middle-ends and back-ends from scratch that can use all information > available in such programs and that produce high-quality code for a > range of architectures is undoable for most if not all research > labs. > > And it should also not be necessary: many excellent lower-level > language compilers already exist, some of which support a wide range > of architectures, such as LLVM (OoO CPUs, VLIWs, GPUs, CGRAs in my > own backend and in Samsung's proprietary SRP backend, etc.). So for > research purposes and hopefully later also real-world development if > the research results are good, ideally we would have to only develop > the necessary precompiler tools that take in very high-level code > and that produce tuned lower-level (C or bitcode or LLVM IR or ...) > after high-level analysis and target-dependent optimisations and > selections, after which LLVM then takes care of the further > low-level optimizations and specific code generation for the > different targets in the heterogeneous multicore. > > To facilitate research in this direction and use LLVM in such a tool > flow, it is absolutely necessary that both the precompiler and the > researcher doing manual experiments can steer the low-level LLVM > compiler with code annotations such as loop pragmas or attributes, > simply because once the code is in a lower-level form such as C or > bitcode or LLVM IR, there is not enough information available in the > code itself to select the best low-level transformations. > > It is interesting to note that in such an approach, the precompiler > probably would be trained with machine learning. If this is the > case, it might also be able to learn which annotations actually > influence the compiler and which do not, for example because they > are destroyed before some optimization pass is executed. So the > precompiler can learn to generate code tuned for specific targets > taking into account all limitations of the compiler that will do the > actual code generation, including its incomplete or stupid or > whatever support for pragmas and other such things...+1 This still leaves the question of exactly how to attach metadata to loops, etc. -Hal> > Best, > > Bjorn > > On 21 Nov 2012, at 18:56, Krzysztof Parzyszek > <kparzysz at codeaurora.org> wrote: > > > On 11/21/2012 11:32 AM, Tobias Grosser wrote: > >> On 11/21/2012 03:45 PM, Krzysztof Parzyszek wrote: > >>> > >>> I'm thinking of this in terms of parallelization directives. The > >>> optimizations that rely on such annotations would need to be done > >>> as > >>> early as possible, before any optimization that could invalidate > >>> them. > >>> If the annotation can become false, you are right---it's probably > >>> not a > >>> good idea to have it as the medium. > >> > >> If we use metadata to model annotations, we need to ensure that it > >> is > >> either correct or in case a transformation can not guarantee the > >> correctness of the meta data, that it is removed. > > > > Yes, that is not hard to accomplish. > > > > > >>> Other types of annotations that are > >>> "harmless" are probably good to have, for example "unroll-by" > >>> (assuming > >>> that this is a suggestion to the compiler, not an order). > >> > >> To my knowledge, we are avoiding to allow the user to 'tune' the > >> compiler. Manual tuning may be good for a certain piece of > >> hardware, but > >> will have negative effects on other platforms. > > > > A lot of ISV code is meant to run on a particular platform, or on a > > small set of target platforms. Such code is often hand-tuned and > > the tuning directives will be different for different targets.. I > > see no reason why we shouldn't allow that. As a matter of fact, > > not allowing it will make us less competitive. > > > > > >> Instead of providing facilities to tune the hardware, we should > >> understand why LLVM does not choose the right unrolling factor. > > > > Because in general it's impossible. User's hints are always > > welcome. > > > > -Krzysztof > > > > > > -- > > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, > > hosted by The Linux Foundation > > _______________________________________________ > > 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