[cfe-dev] Define new pragma in Clang
tobias at grosser.es
Tue Nov 27 16:34:54 PST 2012
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.
> 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.
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
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.
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
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.
More information about the cfe-dev