Tests added for record & replay mechanism now require LIBOMP_OMPX_TASKGRAPH=TRUE or =1 CMAKE variable when building. These tests are not run by default to avoid failures, as suggested by @tianshilei1992 .

In D146642#4246126, @protze.joachim wrote:

In D146642#4240082, @yuchenle wrote:

Sorry for the delay. I was trying to generate some data. Hopefully, I will write some scripts to automate this process in the future, so that anyone (including me) can test this patch's performance impact with ease.
I ran Heat propagation simulation (https://github.com/yuchenle/tdg-benchs/tree/master/heat) on an exclusive node of Marenostrum 4 with different granularities and numbers of threads. So far, according to the results (https://www.dropbox.com/s/jur1qrftmw2epvk/LLVM%20RR%20Perf.xlsx?dl=0) the performance impact is small to unnoticeable.

What is the impact to taskbench in the EPCC OpenMP micro benchmark?

Similarly, what is the impact to SPEC OMP 2012 kdtree?

Shielding changes within a macro OMPX_TASKGRAPH. This macro can be defined as 1 or TRUE at CMAKE configuration time via LIBOMP_OMPX_TASKGRAPH. The default value of it is FALSE.

In D146642#4229088, @josemonsalve2 wrote:

In D146642#4229078, @tianshilei1992 wrote:

In D146642#4229069, @josemonsalve2 wrote:

In D146642#4229067, @tianshilei1992 wrote:

In D146642#4229048, @josemonsalve2 wrote:

In D146642#4228996, @tianshilei1992 wrote:

I think it's better to guard the entire related code with macro.

What do you mean by this Shilei? To disable this feature?

Like a opt-in feature.

Why do you think so? What's the harm of leaving it enable as this is just an API function? Are you saying this to save space in the structs?

It's not just an API function. It contains many runtime checks which can potentially compromise the performance for users that don't need the feature. I'd prefer to take it similar to OMPT.

Got it. It can produce a performance degradation in regular tasks, even when not used. I think that's a fair idea.

@yuchenle have you measure the overhead of this in regular tasks when no recording is used? This is specially important for you guys that use fine grain tasking

NUM_TDG_LIMIT is now an env variable KMP_MAX_TDGS.
Reverted a few changes unrelated to task record & replay.

Deleted include <new> in tasking.cpp which was not used
Deleted global variable kmp_max_nesting which is not used in this commit
Merge nested if as suggested
Simplified initialization of is_taskgraph in

__kmp_task_finish

changed TDG_RECORD macro to inlined function
applied clang-format where it was missed
changed TDG tests, so that they now use clangxx instead of clang, and deleted unnecessary "include" in them

Changes according to some of @josemonsalve2 's comments