Hi, I've been looking at several loop pragma discussion threads, and every now and then, people note that it is difficult to ensure that metadata (that would represent the information from the pragma) is not destroyed during optimizations. I understand that in theory CFG transformations might destroy loops, but in practice, I notice that even after heavy optimization with opt and after transformations such as if-conversion in llc, the IR seems to remember where there were loops in the code. At least that is what I make of information such as BB#28: derived from LLVM BB %for.body47.i ... BB#43: derived from LLVM BB %while.body.i.preheader.i ... BB#44: derived from LLVM BB %while.body.i.i ... that gets printed when I run llc with -print-after-all. So apparently, at least some loop information is passed to the compiler backend successfully. As are line numbers, by the way, and pragmas also have line numbers. So I wonder, what is the practical problem with passing information about loop pragmas as metadata on basic blocks? Thanks, Bjorn De Sutter Computer Systems Lab Ghent University
On 11/20/2012 1:56 PM, Bjorn De Sutter wrote:> Hi, > > I've been looking at several loop pragma discussion threads, and every now and then, people note that it is difficult to ensure that metadata (that would represent the information from the pragma) is not destroyed during optimizations. I understand that in theory CFG transformations might destroy loops, but in practice, I notice that even after heavy optimization with opt and after transformations such as if-conversion in llc, the IR seems to remember where there were loops in the code. At least that is what I make of information such as > > BB#28: derived from LLVM BB %for.body47.i > ... > BB#43: derived from LLVM BB %while.body.i.preheader.i > ... > BB#44: derived from LLVM BB %while.body.i.i > ... > > that gets printed when I run llc with -print-after-all. So apparently, at least some loop information is passed to the compiler backend successfully. As are line numbers, by the way, and pragmas also have line numbers. > > So I wonder, what is the practical problem with passing information about loop pragmas as metadata on basic blocks?The problem is that the "BB derived from %for.loop.preheader" doesn't really mean that the BB is still a preheader. -Krzysztof -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
On 11/20/2012 08:56 PM, Bjorn De Sutter wrote:> Hi, > > I've been looking at several loop pragma discussion threads, and every now and then, people note that it is difficult to ensure that metadata (that would represent the information from the pragma) is not destroyed during optimizations. I understand that in theory CFG transformations might destroy loops, but in practice, I notice that even after heavy optimization with opt and after transformations such as if-conversion in llc, the IR seems to remember where there were loops in the code. At least that is what I make of information such as > > BB#28: derived from LLVM BB %for.body47.i > ... > BB#43: derived from LLVM BB %while.body.i.preheader.i > ... > BB#44: derived from LLVM BB %while.body.i.i > ... > > that gets printed when I run llc with -print-after-all. So apparently, at least some loop information is passed to the compiler backend successfully. As are line numbers, by the way, and pragmas also have line numbers. > > So I wonder, what is the practical problem with passing information about loop pragmas as metadata on basic blocks?There are two more points: o Annotations may become invalid Even if the loop structure is unchanged, annotations may become invalid. A loop may e.g. not be parallel any more as loop invariant code motion can introduce additional dependences. o Blocks future optimizations At the moment LLVM performs little loop optimizations. Hence, the original structure is not changed too much. However, future optimizations within core LLVM may change this behavior. Relying on the absence of certain transformations, does not seem to be a future proof concept. There are probably ways to carefully design annotations on loops, but it is a difficult problem. I propose to discuss the kind of annotation you want to put and we can than try to find a proper way to represent annotations. For annotations like '#pragma ivdep', it may e.g. be better to not mark a certain loop, but to directly mark the memory loads/stores within that loop to not carrying dependences of a certain kind. Cheers Tobi
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