[LLVMdev] loop pragmas

[Tobias Grosser]

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