[flang-commits] [flang] [flang][cmake] Order flang profdata generation after clang's (PR #206023)

[Madhur Amilkanthwar via flang-commits]

================
@@ -281,6 +281,14 @@ if(LLVM_BUILD_INSTRUMENTED)
     )
     add_custom_target(generate-flang-profdata DEPENDS "${PROFDATA}")
 
+    # The clang and flang profdata pipelines clean and regenerate the same
+    # shared profraw directories (profiles/ and clang/utils/perf-training).
+    # Order flang after clang so flang's clean/regenerate never races clang's
+    # merge while it has a profraw mmap'd.
+    if(TARGET generate-profdata)
+      add_dependencies(generate-flang-profdata generate-profdata)
----------------
madhur13490 wrote:

I am not expert in this area but I did some analysis.

I think the biggest problem is that we are using different config. Your config seems to be flang-driven and we are clang-driven + flang enabled in project list. 

Here is my analysis: Let's look at two lines.

1.  https://github.com/llvm/llvm-project/blob/6a12b7c74b179fbd1b40466f57d94dd8ed53cf16/clang/CMakeLists.txt#L823
2. https://github.com/llvm/llvm-project/blob/6a12b7c74b179fbd1b40466f57d94dd8ed53cf16/flang/test/CMakeLists.txt#L289

The key is what clang-bootstrap-deps depends on, which is governed by PGO_OPT_PROFDATA_PROVIDER, and that differs between the two ways this feature is used.

Both these lines do add_dependencies(clang-bootstrap-deps <X>):

[clang/CMakeLists.txt:823](https://github.com/llvm/llvm-project/blob/6a12b7c74b179fbd1b40466f57d94dd8ed53cf16/clang/CMakeLists.txt#L823) → adds ${PGO_OPT_PROFDATA_PROVIDER}
[flang/test/CMakeLists.txt:289](https://github.com/llvm/llvm-project/blob/6a12b7c74b179fbd1b40466f57d94dd8ed53cf16/flang/test/CMakeLists.txt#L289) → adds generate-flang-profdata

1. Flang-driven build (your config, flang/cmake/caches/*): the cache sets PGO_OPT_PROFDATA_PROVIDER = generate-flang-profdata. Since clang/CMakeLists.txt:822 sets it with CACHE STRING "" (no FORCE), it does not override that. So line 823 and line 289 add the same target — generate-flang-profdata. clang-bootstrap-deps ends up with a single profdata pipeline; generate-profdata exists but is never attached. One pipeline → the merge reliably runs after all profraw within that one add_custom_command (exactly as you noted) → no race. This is why you don't reproduce it, and why flang.profdata is the one used while clang.profdata isn't.

2. Clang-driven build with flang in the project list (the configuration we build): the clang cache (clang/cmake/caches/BOLT-PGO.cmake) leaves PGO_OPT_PROFDATA_PROVIDER = generate-profdata. So line 823 adds generate-profdata and line 289 adds generate-flang-profdata — two different targets, both direct prerequisites of clang-bootstrap-deps, with no edge between them. ninja runs them concurrently; each does clean → regenerate profraw → llvm-profdata merge over the same profiles/ and clang/utils/perf-training dirs, so one truncates a profraw the other has mmap'd → intermittent SIGBUS in llvm-profdata. (Here clang.profdata is the one actually used; flang.profdata is produced but unused.)

So it's not a contradiction between our observations — it's two different dependency graphs selected by PGO_OPT_PROFDATA_PROVIDER.

I updated the patch so that the ordering edge is now guarded to apply only in the two-pipeline case and I further validated both graphs with ninja -t query tools/flang/test/generate-flang-profdata:

provider generate-profdata (clang-driven): input list now includes tools/clang/utils/perf-training/generate-profdata → the two pipelines are serialized.

provider generate-flang-profdata (flang-driven, your config): the edge is absent → strict no-op, your flow is unchanged (so no duplicate clang.profdata / extra work).

I think we can give this patch a chance and observe if this fixes the intermittent issue. (As of now we are keeping our CI happy using `BOOTSTRAP_FLANG_PGO_TRAINING_CLANG_COUPLING=OFF` but we'd like flang enabled)

https://github.com/llvm/llvm-project/pull/206023