Why do you need it? CapturedExpr should be emitted as is

It is my mistake in naming the function as getInitialExprFromCapturedExpr(). It should have been getCapturedExprFromImplicitCastExpr( ). The function extracts the OMPCapturedExpr from within the clause.
clause->getCondition() does not give me the OMPCapturedExpr.

(gdb) NoContextC->getCondition()->dump()
ImplicitCastExpr 0x678640 'int' <LValueToRValue>
  `-DeclRefExpr 0x678620 'int' lvalue OMPCapturedExpr 0x6785a0 '.capture_expr.' 'int'

NoContextC is of type OMPNocontextClause *.
If there is a simpler way to get the OMPCapturedExpr please tell me.

At present, I will rename the function name.

Why do you need to dig for the captured expr here?

While generating the If-else statement in EmitIfElse(), I am using
llvm::Value *CondValue = CGF->EvaluateExprAsBool(Condition);
and
CGF->Builder.CreateCondBr(CondValue, ThenBlock, ElseBlock);
The EvaluateExprAsBool needs a CapturedExpr. Using NoContextC->getCondition() results in a core dump.

It means, the context (capturedstmt) does not know about this capturedexpr, which means it is captured in the wrong context. You're not fixing the problem, you're overcoming it with this hack. Need to capture the expression in the correct context and emit in the correct context

I use S.clauses() to get the list of all the clauses (type OMPClause) present in the dispatch directive. The example of NoContextC of type OMPClause contains ImplicitCastExpr. An OMPClause cannot be changed to contain capturedExpr. I think I am not able to understand where do you want me to change it. Can you please clarify?

Why this is a warning, not an error?

This message is to indicate the user that if novariants and nocontext are specified then novariants is taken into account. This warning is to inform the user and not an error.

Why it is not an error?

I do not need to stop execution if novariants and nocontext occur together. In a dispatch directive like #pragma omp dispatch nocontext(c1) novariants(c2) then I do not find a way to generate

if(condition)
    foo();
else
   foo_variant

For the "condition" in if statement I do not know a way to use c1 & c2 together. Hence I preferred to indicate this to user and use novariants(c2). I do not want to stop the compilation with an error message because the spec does not indicate what to do in this case.

Should it be just c1 || c2? What's the problem in emitting the combined expression?

I see this in the standard:
If do-not-use-variant evaluates to true, no function variant is selected for the target-call of the
13 dispatch region associated with the novariants clause even if one would be selected
14 normally.

Doe it mean that novariant has higher priority than nocontext?

This relates only to the novariants clause only. However, I can extrapolate the spec to mean whatever I have implemented. It will be good to provide a warning.
If you feel that warning is not needed then I can remove it but, the user should not be left wondering why nocontext was not considered.

@dreachem thoughts?

The effect of the nocontext clause is to not add the dispatch construct to the construct trait set. It will only matter once we support dispatch in a construct trait selector (support for this is not required in 5.2, but is required in 6.0).

Assuming we support dispatch in a construct trait selector, then this is what the various combinations would mean:

novariants(0), nocontext(0): Allow selective variant substitution according to context match
novariants(0), nocontext(1): Allow selective variant substitution according to context match (NO MATCH
                             for selectors that require **dispatch** trait)
novariants(1), nocontext(0): Always call the base function (shuts off any variant substitution for the call)
novariants(1), nocontext(1): Always call the base function (shuts off any variant substitution for the call)

In summary, novariants takes precedence and nocontext can be ignored ONLY if the do-not-use-variant argument evaluates to true.

Alexey,
I have added support for clauses novariants and nocontext occuring on the same dispatch directive and removed the warning message.
Can you please review the code?
--Sunil

I rather doubt it will correctly with constructors/destructors

Do you have an example of constructors/destructors where it will not work? The codegen for the nocontext & novariant clauses occurring together is present in the lit test case. I have written the code according to truth table mentioned by Deepak:

novariants(0), nocontext(0): Allow selective variant substitution according to context match
novariants(0), nocontext(1): Allow selective variant substitution according to context match (NO MATCH
                             for selectors that require **dispatch** trait)
novariants(1), nocontext(0): Always call the base function (shuts off any variant substitution for the call)
novariants(1), nocontext(1): Always call the base function (shuts off any variant substitution for the call)

Try to add tests with classes, which evaluate to boolean, and create immediate class instance and see, that the destructors are called correctly

@alexey-bataev Both @SunilKuravinakop and I are unclear what test you're asking for here.

When you say "test with classes", do you mean that the called function (and its variant) should have a local declaration of a variable of class type? Such as:

void f_v()
{
   MyType2 v; // MyType2 constructor called on v
   ...
   // MyType2 destructor called on v

}

#pragma omp declare variant(f_v) match(construct={dispatch})
void f()
{
   MyType v; // MyType constructor called on v
   ...
   // MyType destructor called on v
}

int main()
{
   #pragma omp dispatch
   f();
}

But then, what do you mean by "which evaluate to boolean"?

Can you provide a quick sketch of what this test should be doing?

No, I thought about the condition, which involves instantiation of the class, to check that the codegen handles correctly constructors/destructors calls (that's always a problem in C++). Is it possible to create a condition, that includes class, something like:

class AAA {
...
};
#pragma omp dispatch if(AAA()) <---- the constructor and then destructor is called here
...

Thanks for the clarification. So something like this?

#include <iostream>                                                                                                                                                                                                                                                          
int main()
{
    class IsPositive {
public:
    IsPositive(int x) : _x(x) {
        std::cout << "constructing IsPositive(" << x << ") object\n";
    }
    ~IsPositive() {
        std::cout << "destructing IsPositive(" << _x << ") object\n";
    }
    operator bool() const { return _x > 0; }
private:
        int _x;
    };

  // case 1
#pragma omp parallel if(IsPositive(10))
    {
        std::cout << "[1] in parallel\n";
    }

  // case 2
    auto cond1 = IsPositive(5);
#pragma omp parallel if(cond1)
    {
        std::cout << "[2] in parallel\n";
    }

  // case 3
#pragma omp parallel if(IsPositive(-10))
    {
        std::cout << "[3] in parallel\n";
    }

  // case 4
    auto cond2 = IsPositive(-5);
#pragma omp parallel if(cond2)
    {
        std::cout << "[4] in parallel\n";
    }

  

The output for the above with OMP_NUM_THREADS=2 is:

constructing IsPositive(10) object
[1] in parallel
[1] in parallel
destructing IsPositive(10) object
constructing IsPositive(5) object
[2] in parallel
[2] in parallel
constructing IsPositive(-10) object
[3] in parallel
destructing IsPositive(-10) object
constructing IsPositive(-5) object
[4] in parallel
destructing IsPositive(-5) object
destructing IsPositive(5) object

So, the destructor for the instantiated class object used in the if condition is called upon completing each parallel region. On the other hand, if I move the condition expression outside the directive (as for cases 2 and 4), then the destructor for the instantiated class is called at the end of the function.

Does this match the expected behavior?

Yes, something like this but for dispatch. We need to handle classes construction/deconstruction correctly, I just want to be sure that we don't miss anything here and avoid bugs, that will require significant efforts to fix/rework later.

I still think these functions should not be needed, if something is required, it should be build in Sema and stored in AST. If you need to replace some AST values by some LVM IR values, use OpaqueValue nodes, which can be replaced in codegen by special RAIIs.

Can you please clarify your comment based on my following points?

1. There is a pre-computed call trait (pre-computed in Sema) stored in AnnotateAttr. I am using those AnnotateAttrs in transformCallInStmt. In replaceWithNewTraitsOrDirectCall I am trying to set the call based on BinaryExpr under the dispatch directive.
2. If you want me to pre-compute and store it in Sema I will have to clone the CDecl and store it. Earlier, in the helper functions (in Sema), I created new AST attributes, but according to your suggestion now I will have to store it in AnnotateAttr.
3. An OpaqueValueExpr node copies the pointer of the SourceExpr. This does not help in noting the alternative call trait.

The problem with these transformations is that sometimes they do not work as expected and miss some cases. Especially it happens with C++, which has lots of idioms like classes (especially inheritance), templates, implicit conversions (functions), etc. All these tree traversal techniques tend to be not fully correct in many cases. That;s why the preferred way to build helper expressions is doing it in Sema, because Sema knows how to handle all these cases correctly, but codegen does not. That's why I'm asking about compatibility with C++, it has lots of corner cases, and it would be good somehow to handle them in this patch rather than fixing it later

Try to add tests with classes, which evaluate to boolean, and create immediate class instance and see, that the destructors are called correctly

The tests with classes and function members are required, as well as classes, used in conditions