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 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.
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.