[cfe-dev] Define new pragma in Clang

[Tobias Grosser]

On 11/27/2012 07:13 PM, Tigran wrote:
> Hi Tobi,
>
> Thank you for your answer.
> The information that I want to pass is just an unsigned integer number.

Sure, but what is the meaning of the number?

I ask as depending on the meaning of the number, there may be different 
ways represent it at LLVM-IR level.


 > The
> idea to attach the pragma to the statement sounds good for me, if it is
> possible then I can attach that to the 'for' loop statement. But it is not
> clear for me how to find that 'for' loop statement in clang CodeGen?

That's exactly the problem. There is no 'for' loop statement. LLVM-IR 
just knows about sequential basic blocks and goto statements which 
together form a control flow graph. The LoopInfo analysis can detect 
loops in this control flow graph, but especially after a couple of 
transformations, it is hard to understand if and how the detected loops 
relate to the loops in the original C program. Specifically, there is 
not a specific statement that is representative of a loop and that can 
be used to attach information about source level loop pragmas.

Hence, depending on what kind of information is provided at the source 
level, there may be different ways to keep this information at IR-level.

Some examples:

#pragma save-to-speculate
for (int i = 0; i < foo(i); i++)

The semantics of save-to-speculate pragma could be that if foo(i) is 
false, then for all x > i foo(x) is false. This means, we can easily 
execute more iterations of the loop, as long as they are predicated by 
foo(x).
To represent such information, we could attach information to the 
instruction that checks the exit condition of the loop. As the pragma 
does not depend on the content of the loop, there is no need to relate 
it to the individual instructions in the loop. Even if loop invariant 
code motion or other transformations happen, they do not change the 
behavior of the exit condition.

#pragma minimal-num-iterations(100)
for (int i = b; i < foo(i); i++)

To store information about the minimal number of loop iterations, we 
could again attach information to the instruction that exits the loop. 
Stating e.g. that the first 100 calls to it will yield true.

#pragma omp parallel
for (...

Correctly describing that a loop can be executed in parallel is a lot 
more difficult. Seemingly unrelated changes to the loop body can 
introduce new dependences that make parallel execution invalid. Loop 
invariant code motion or reg2mem can e.g. introduce such dependences. 
Hence, just attaching the pragma to the loop iv or the exiting condition 
is insufficient. Hal posted at some point a proposal how to represent 
this. In general it is not easy, as we need to find a way that does not 
block valuable compiler transformations, but that at the same time 
ensures that we detect if the semantics of the loop body changed in a 
way that parallel execution is not valid any more.

Hence, I believe it is important to decide on a case by case basis what 
information we want to forward to LLVM-IR and how to represent it.

Cheers
Tobi