On 11/21/2012 6:53 AM, Tobias Grosser wrote:> > o Blocks future optimizations > > At the moment LLVM performs little loop optimizations. Hence, the > original structure is not changed too much.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. 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). -Krzysztof -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
On 11/21/2012 03:45 PM, Krzysztof Parzyszek wrote:> On 11/21/2012 6:53 AM, Tobias Grosser wrote: >> >> o Blocks future optimizations >> >> At the moment LLVM performs little loop optimizations. Hence, the >> original structure is not changed too much. > > 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. The next point is that we should choose a meta-data representation that is not removed by the most trivial transformation.> 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. Instead of providing facilities to tune the hardware, we should understand why LLVM does not choose the right unrolling factor. Maybe there is additional information that can help LLVM to derive that information. Cheers Tobi
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
> 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. Note that LLVM is typically the "backend" compiler portion of a combined compiler that does language specific stuff. It would be useful to have a way for such a front-end compiler to, if it so desires, annotate transformation like loop unroll factors if there's machinery to implement the transformation. I'd actually prefer such directives to actually be orders rather than suggestions, unless they specify impossible things. In a personal capacity, I'm very interested in auto-tuning pieces of software -- think ATLAS or SPIRAL -- where the ability to empirically try various alternatives on a new hardware platform is very useful. | Instead of providing facilities to tune the hardware, we should | understand why LLVM does not choose the right unrolling factor. Maybe | there is additional information that can help LLVM to derive that | information. This is a laudable goal, but there always comes up the issue that developing understanding of why things perform in a particular way on a modern CPU/memory/chipset combination requires manpower, often more manpower than is available. Regards, Dave