[LLVMdev] loop pragmas

[Bjorn De Sutter]

On 27 Nov 2012, at 15:03, Hal Finkel <hfinkel at anl.gov> wrote:

> ----- 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.
>> 
>> ...
>> 
>> 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.
>> 
>> ...
> 
> +1
> 
> This still leaves the question of exactly how to attach metadata to loops, etc.
> -Hal
> 

What about the following: 

1) During parsing, pragmas and attributes and ... are collected and stored in some kind of annotation container. Every occurrence of a pragma, attribute, etc. ends up as a pseudo instruction in the IR that references one annotation in the container. Per annotation, generic information such as its type is stored, potential parameters, line number information, etc. 

2) Additional passes can extend the information tracked for each annotation: for example, for loop pragmas, some small pass could compute the nesting depth of each pragma. For data dependency related loop params, the loop annotation can be converted into per instruction metadata, etc. Also additional pseudo-instructions can be inserted. Similar passes can check which annotations are still meaningful, or aggregate information from multiple annotations. This might be useful, for example to omit loop annotations on loops that were unrolled completely, or to aggregate annotations when loops are fused (by polly e.g.). 

3) Each and every code transformation pass is responsible for either maintaining the annotations or for invalidating them. The standard behavior would be to invalidate all annotations. It is up to the developers of passes using the annotations to make sure that the annotations survive it to their pass. A second step would be to invalidate only the annotations referenced by pseudo-instructions that are involved in the transformations. This can also be done in post-processing steps of transformations: for example, if some pseudo-instruction is not at a loop nest level indicated by the annotation it references, the data is invalid. Or if more than one pseudo instruction refers to an annotation after some transformation, this points to duplication which might invalidate some annotation. 

Bjorn