[clang] [llvm] [CMake][Release] Enable CMAKE_POSITION_INDEPENDENT_CODE (PR #90139)
https://github.com/tstellar created
https://github.com/llvm/llvm-project/pull/90139
Set this in the cache file directly instead of via the test-release.sh script
so that the release builds can be reproduced with just the cache file.
>From 67f3d1ede686758238bb37a2ea50790750f7693f Mon Sep 17 00:00:00 2001
From: Tom Stellard
Date: Wed, 24 Apr 2024 07:57:09 -0700
Subject: [PATCH] [CMake][Release] Enable CMAKE_POSITION_INDEPENDENT_CODE
Set this in the cache file directly instead of via the test-release.sh
script so that the release builds can be reproduced with just the
cache file.
---
clang/cmake/caches/Release.cmake | 1 +
llvm/utils/release/test-release.sh | 3 +--
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/clang/cmake/caches/Release.cmake b/clang/cmake/caches/Release.cmake
index c164d5497275f3..c0bfcbdfc1c2ae 100644
--- a/clang/cmake/caches/Release.cmake
+++ b/clang/cmake/caches/Release.cmake
@@ -82,6 +82,7 @@ set(LLVM_ENABLE_PROJECTS ${STAGE1_PROJECTS} CACHE STRING "")
# stage2-instrumented and Final Stage Config:
# Options that need to be set in both the instrumented stage (if we are doing
# a pgo build) and the final stage.
+set_instrument_and_final_stage_var(CMAKE_POSITION_INDEPENDENT_CODE "ON" STRING)
set_instrument_and_final_stage_var(LLVM_ENABLE_LTO
"${LLVM_RELEASE_ENABLE_LTO}" STRING)
if (LLVM_RELEASE_ENABLE_LTO)
set_instrument_and_final_stage_var(LLVM_ENABLE_LLD "ON" BOOL)
diff --git a/llvm/utils/release/test-release.sh
b/llvm/utils/release/test-release.sh
index 4314b565e11b03..050004aa08c493 100755
--- a/llvm/utils/release/test-release.sh
+++ b/llvm/utils/release/test-release.sh
@@ -353,8 +353,7 @@ function build_with_cmake_cache() {
env CC="$c_compiler" CXX="$cxx_compiler" \
cmake -G "$generator" -B $CMakeBuildDir -S $SrcDir/llvm \
-C $SrcDir/clang/cmake/caches/Release.cmake \
-
-DCLANG_BOOTSTRAP_PASSTHROUGH="CMAKE_POSITION_INDEPENDENT_CODE;LLVM_LIT_ARGS" \
--DCMAKE_POSITION_INDEPENDENT_CODE=ON \
+ -DCLANG_BOOTSTRAP_PASSTHROUGH="LLVM_LIT_ARGS" \
-DLLVM_LIT_ARGS="-j $NumJobs $LitVerbose" \
$ExtraConfigureFlags
2>&1 | tee $LogDir/llvm.configure-$Flavor.log
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CMake][Release] Use the TGZ cpack generator for binaries (PR #90138)
https://github.com/tstellar created
https://github.com/llvm/llvm-project/pull/90138
None
>From 0d0484ac99affdc8ccb9bc3a1eff827cf996c51c Mon Sep 17 00:00:00 2001
From: Tom Stellard
Date: Wed, 24 Apr 2024 07:54:41 -0700
Subject: [PATCH] [CMake][Release] Use the TGZ cpack generator for binaries
---
clang/cmake/caches/Release.cmake | 1 +
1 file changed, 1 insertion(+)
diff --git a/clang/cmake/caches/Release.cmake b/clang/cmake/caches/Release.cmake
index c164d5497275f3..aa7e6f99e94d52 100644
--- a/clang/cmake/caches/Release.cmake
+++ b/clang/cmake/caches/Release.cmake
@@ -90,4 +90,5 @@ endif()
# Final Stage Config (stage2)
set_final_stage_var(LLVM_ENABLE_RUNTIMES "${LLVM_RELEASE_ENABLE_RUNTIMES}"
STRING)
set_final_stage_var(LLVM_ENABLE_PROJECTS "${LLVM_RELEASE_ENABLE_PROJECTS}"
STRING)
+set_final_stage_var(CPACK_GENERATOR "TGZ" STRING)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CMake][Release] Refactor cache file and use two stages for non-PGO builds (PR #89812)
https://github.com/tstellar closed https://github.com/llvm/llvm-project/pull/89812 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CMake][Release] Refactor cache file and use two stages for non-PGO builds (PR #89812)
https://github.com/tstellar updated
https://github.com/llvm/llvm-project/pull/89812
>From 275979816a1de8b16a6c45b5ee2ef4e73c8828ba Mon Sep 17 00:00:00 2001
From: Tom Stellard
Date: Tue, 23 Apr 2024 19:29:04 +
Subject: [PATCH] [CMake][Release] Refactor cache file and use two stages for
non-PGO builds
Completely refactor the cache file to simplify it and remove unnecessary
variables. The main functional change here is that the non-PGO builds now
use two stages, so `ninja -C build stage2-package` can be used with both
PGO and non-PGO builds.
---
clang/cmake/caches/Release.cmake | 134 +++
1 file changed, 67 insertions(+), 67 deletions(-)
diff --git a/clang/cmake/caches/Release.cmake b/clang/cmake/caches/Release.cmake
index bd1f688d61a7ea..c164d5497275f3 100644
--- a/clang/cmake/caches/Release.cmake
+++ b/clang/cmake/caches/Release.cmake
@@ -1,93 +1,93 @@
# Plain options configure the first build.
# BOOTSTRAP_* options configure the second build.
# BOOTSTRAP_BOOTSTRAP_* options configure the third build.
+# PGO Builds have 3 stages (stage1, stage2-instrumented, stage2)
+# non-PGO Builds have 2 stages (stage1, stage2)
-# General Options
+
+function (set_final_stage_var name value type)
+ if (LLVM_RELEASE_ENABLE_PGO)
+set(BOOTSTRAP_BOOTSTRAP_${name} ${value} CACHE ${type} "")
+ else()
+set(BOOTSTRAP_${name} ${value} CACHE ${type} "")
+ endif()
+endfunction()
+
+function (set_instrument_and_final_stage_var name value type)
+ # This sets the varaible for the final stage in non-PGO builds and in
+ # the stage2-instrumented stage for PGO builds.
+ set(BOOTSTRAP_${name} ${value} CACHE ${type} "")
+ if (LLVM_RELEASE_ENABLE_PGO)
+# Set the variable in the final stage for PGO builds.
+set(BOOTSTRAP_BOOTSTRAP_${name} ${value} CACHE ${type} "")
+ endif()
+endfunction()
+
+# General Options:
+# If you want to override any of the LLVM_RELEASE_* variables you can set them
+# on the command line via -D, but you need to do this before you pass this
+# cache file to CMake via -C. e.g.
+#
+# cmake -D LLVM_RELEASE_ENABLE_PGO=ON -C Release.cmake
set(LLVM_RELEASE_ENABLE_LTO THIN CACHE STRING "")
set(LLVM_RELEASE_ENABLE_PGO OFF CACHE BOOL "")
-
+set(LLVM_RELEASE_ENABLE_RUNTIMES "compiler-rt;libcxx;libcxxabi;libunwind"
CACHE STRING "")
+set(LLVM_RELEASE_ENABLE_PROJECTS
"clang;lld;lldb;clang-tools-extra;bolt;polly;mlir;flang" CACHE STRING "")
+# Note we don't need to add install here, since it is one of the pre-defined
+# steps.
+set(LLVM_RELEASE_FINAL_STAGE_TARGETS
"clang;package;check-all;check-llvm;check-clang" CACHE STRING "")
set(CMAKE_BUILD_TYPE RELEASE CACHE STRING "")
-# Stage 1 Bootstrap Setup
+# Stage 1 Options
+set(LLVM_TARGETS_TO_BUILD Native CACHE STRING "")
set(CLANG_ENABLE_BOOTSTRAP ON CACHE BOOL "")
+
+set(STAGE1_PROJECTS "clang")
+set(STAGE1_RUNTIMES "")
+
if (LLVM_RELEASE_ENABLE_PGO)
+ list(APPEND STAGE1_PROJECTS "lld")
+ list(APPEND STAGE1_RUNTIMES "compiler-rt")
set(CLANG_BOOTSTRAP_TARGETS
generate-profdata
-stage2
+stage2-package
stage2-clang
-stage2-distribution
stage2-install
-stage2-install-distribution
-stage2-install-distribution-toolchain
stage2-check-all
stage2-check-llvm
-stage2-check-clang
-stage2-test-suite CACHE STRING "")
-else()
- set(CLANG_BOOTSTRAP_TARGETS
-clang
-check-all
-check-llvm
-check-clang
-test-suite
-stage3
-stage3-clang
-stage3-check-all
-stage3-check-llvm
-stage3-check-clang
-stage3-install
-stage3-test-suite CACHE STRING "")
-endif()
+stage2-check-clang CACHE STRING "")
-# Stage 1 Options
-set(STAGE1_PROJECTS "clang")
-set(STAGE1_RUNTIMES "")
+ # Configuration for stage2-instrumented
+ set(BOOTSTRAP_CLANG_ENABLE_BOOTSTRAP ON CACHE STRING "")
+ # This enables the build targets for the final stage which is called stage2.
+ set(BOOTSTRAP_CLANG_BOOTSTRAP_TARGETS ${LLVM_RELEASE_FINAL_STAGE_TARGETS}
CACHE STRING "")
+ set(BOOTSTRAP_LLVM_BUILD_INSTRUMENTED IR CACHE STRING "")
+ set(BOOTSTRAP_LLVM_ENABLE_RUNTIMES "compiler-rt" CACHE STRING "")
+ set(BOOTSTRAP_LLVM_ENABLE_PROJECTS "clang;lld" CACHE STRING "")
-if (LLVM_RELEASE_ENABLE_PGO)
- list(APPEND STAGE1_PROJECTS "lld")
- list(APPEND STAGE1_RUNTIMES "compiler-rt")
+else()
+ if (LLVM_RELEASE_ENABLE_LTO)
+list(APPEND STAGE1_PROJECTS "lld")
+ endif()
+ # Any targets added here will be given the target name stage2-${target}, so
+ # if you want to run them you can just use:
+ # ninja -C $BUILDDIR stage2-${target}
+ set(CLANG_BOOTSTRAP_TARGETS ${LLVM_RELEASE_FINAL_STAGE_TARGETS} CACHE STRING
"")
endif()
+# Stage 1 Common Config
set(LLVM_ENABLE_RUNTIMES ${STAGE1_RUNTIMES} CACHE STRING "")
set(LLVM_ENABLE_PROJECTS ${STAGE1_PROJECTS} CACHE STRING "")
-set(LLVM_TARGETS_TO_BUILD Native CACHE STRING "")
-
-# Stage 2 Bootstrap Setup
-set(BOOTSTRAP_CLANG_ENABLE_BOOTSTRAP ON CACHE STRING "")
-set(BOOTSTRAP_CLANG_BOOTSTRAP_TARGETS
-
[clang] [CMake][Release] Refactor cache file and use two stages for non-PGO builds (PR #89812)
tstellar wrote: I've been testing this with #89521. https://github.com/llvm/llvm-project/pull/89812 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CMake][Release] Add stage2-package target (PR #89517)
https://github.com/tstellar closed https://github.com/llvm/llvm-project/pull/89517 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CMake][Release] Refactor cache file and use two stages for non-PGO builds (PR #89812)
https://github.com/tstellar created
https://github.com/llvm/llvm-project/pull/89812
Completely refactor the cache file to simplify it and remove unnecessary
variables. The main functional change here is that the non-PGO builds now use
two stages, so `ninja -C build stage2-package` can be used with both PGO and
non-PGO builds.
>From 275979816a1de8b16a6c45b5ee2ef4e73c8828ba Mon Sep 17 00:00:00 2001
From: Tom Stellard
Date: Tue, 23 Apr 2024 19:29:04 +
Subject: [PATCH] [CMake][Release] Refactor cache file and use two stages for
non-PGO builds
Completely refactor the cache file to simplify it and remove unnecessary
variables. The main functional change here is that the non-PGO builds now
use two stages, so `ninja -C build stage2-package` can be used with both
PGO and non-PGO builds.
---
clang/cmake/caches/Release.cmake | 134 +++
1 file changed, 67 insertions(+), 67 deletions(-)
diff --git a/clang/cmake/caches/Release.cmake b/clang/cmake/caches/Release.cmake
index bd1f688d61a7ea..c164d5497275f3 100644
--- a/clang/cmake/caches/Release.cmake
+++ b/clang/cmake/caches/Release.cmake
@@ -1,93 +1,93 @@
# Plain options configure the first build.
# BOOTSTRAP_* options configure the second build.
# BOOTSTRAP_BOOTSTRAP_* options configure the third build.
+# PGO Builds have 3 stages (stage1, stage2-instrumented, stage2)
+# non-PGO Builds have 2 stages (stage1, stage2)
-# General Options
+
+function (set_final_stage_var name value type)
+ if (LLVM_RELEASE_ENABLE_PGO)
+set(BOOTSTRAP_BOOTSTRAP_${name} ${value} CACHE ${type} "")
+ else()
+set(BOOTSTRAP_${name} ${value} CACHE ${type} "")
+ endif()
+endfunction()
+
+function (set_instrument_and_final_stage_var name value type)
+ # This sets the varaible for the final stage in non-PGO builds and in
+ # the stage2-instrumented stage for PGO builds.
+ set(BOOTSTRAP_${name} ${value} CACHE ${type} "")
+ if (LLVM_RELEASE_ENABLE_PGO)
+# Set the variable in the final stage for PGO builds.
+set(BOOTSTRAP_BOOTSTRAP_${name} ${value} CACHE ${type} "")
+ endif()
+endfunction()
+
+# General Options:
+# If you want to override any of the LLVM_RELEASE_* variables you can set them
+# on the command line via -D, but you need to do this before you pass this
+# cache file to CMake via -C. e.g.
+#
+# cmake -D LLVM_RELEASE_ENABLE_PGO=ON -C Release.cmake
set(LLVM_RELEASE_ENABLE_LTO THIN CACHE STRING "")
set(LLVM_RELEASE_ENABLE_PGO OFF CACHE BOOL "")
-
+set(LLVM_RELEASE_ENABLE_RUNTIMES "compiler-rt;libcxx;libcxxabi;libunwind"
CACHE STRING "")
+set(LLVM_RELEASE_ENABLE_PROJECTS
"clang;lld;lldb;clang-tools-extra;bolt;polly;mlir;flang" CACHE STRING "")
+# Note we don't need to add install here, since it is one of the pre-defined
+# steps.
+set(LLVM_RELEASE_FINAL_STAGE_TARGETS
"clang;package;check-all;check-llvm;check-clang" CACHE STRING "")
set(CMAKE_BUILD_TYPE RELEASE CACHE STRING "")
-# Stage 1 Bootstrap Setup
+# Stage 1 Options
+set(LLVM_TARGETS_TO_BUILD Native CACHE STRING "")
set(CLANG_ENABLE_BOOTSTRAP ON CACHE BOOL "")
+
+set(STAGE1_PROJECTS "clang")
+set(STAGE1_RUNTIMES "")
+
if (LLVM_RELEASE_ENABLE_PGO)
+ list(APPEND STAGE1_PROJECTS "lld")
+ list(APPEND STAGE1_RUNTIMES "compiler-rt")
set(CLANG_BOOTSTRAP_TARGETS
generate-profdata
-stage2
+stage2-package
stage2-clang
-stage2-distribution
stage2-install
-stage2-install-distribution
-stage2-install-distribution-toolchain
stage2-check-all
stage2-check-llvm
-stage2-check-clang
-stage2-test-suite CACHE STRING "")
-else()
- set(CLANG_BOOTSTRAP_TARGETS
-clang
-check-all
-check-llvm
-check-clang
-test-suite
-stage3
-stage3-clang
-stage3-check-all
-stage3-check-llvm
-stage3-check-clang
-stage3-install
-stage3-test-suite CACHE STRING "")
-endif()
+stage2-check-clang CACHE STRING "")
-# Stage 1 Options
-set(STAGE1_PROJECTS "clang")
-set(STAGE1_RUNTIMES "")
+ # Configuration for stage2-instrumented
+ set(BOOTSTRAP_CLANG_ENABLE_BOOTSTRAP ON CACHE STRING "")
+ # This enables the build targets for the final stage which is called stage2.
+ set(BOOTSTRAP_CLANG_BOOTSTRAP_TARGETS ${LLVM_RELEASE_FINAL_STAGE_TARGETS}
CACHE STRING "")
+ set(BOOTSTRAP_LLVM_BUILD_INSTRUMENTED IR CACHE STRING "")
+ set(BOOTSTRAP_LLVM_ENABLE_RUNTIMES "compiler-rt" CACHE STRING "")
+ set(BOOTSTRAP_LLVM_ENABLE_PROJECTS "clang;lld" CACHE STRING "")
-if (LLVM_RELEASE_ENABLE_PGO)
- list(APPEND STAGE1_PROJECTS "lld")
- list(APPEND STAGE1_RUNTIMES "compiler-rt")
+else()
+ if (LLVM_RELEASE_ENABLE_LTO)
+list(APPEND STAGE1_PROJECTS "lld")
+ endif()
+ # Any targets added here will be given the target name stage2-${target}, so
+ # if you want to run them you can just use:
+ # ninja -C $BUILDDIR stage2-${target}
+ set(CLANG_BOOTSTRAP_TARGETS ${LLVM_RELEASE_FINAL_STAGE_TARGETS} CACHE STRING
"")
endif()
+# Stage 1 Common Config
set(LLVM_ENABLE_RUNTIMES ${STAGE1_RUNTIMES} CACHE STRING
[clang] [llvm] [cmake] Remove custom linker flag check function (PR #86602)
tstellar wrote: @petrhosek Would you be able to add a comment to the llvm_check_linker_flag function explaining this so someone else doesn't try to do the same thing. https://github.com/llvm/llvm-project/pull/86602 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [cmake] Remove custom linker flag check function (PR #86602)
https://github.com/tstellar approved this pull request. LGTM. https://github.com/llvm/llvm-project/pull/86602 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CMake][Release] Add stage2-package target (PR #89517)
https://github.com/tstellar created https://github.com/llvm/llvm-project/pull/89517 This target will be used to generate the release binary package for uploading to GitHub. >From 79e4f21df778ede9238c66e06ca289d7599f9f5c Mon Sep 17 00:00:00 2001 From: Tom Stellard Date: Mon, 15 Apr 2024 12:03:33 -0700 Subject: [PATCH] [CMake][Release] Add stage2-package target This target will be used to generate the release binary package for uploading to GitHub. --- clang/cmake/caches/Release.cmake | 2 ++ 1 file changed, 2 insertions(+) diff --git a/clang/cmake/caches/Release.cmake b/clang/cmake/caches/Release.cmake index bd1f688d61a7ea..fa972636553f1f 100644 --- a/clang/cmake/caches/Release.cmake +++ b/clang/cmake/caches/Release.cmake @@ -14,6 +14,7 @@ if (LLVM_RELEASE_ENABLE_PGO) set(CLANG_BOOTSTRAP_TARGETS generate-profdata stage2 +stage2-package stage2-clang stage2-distribution stage2-install @@ -57,6 +58,7 @@ set(LLVM_TARGETS_TO_BUILD Native CACHE STRING "") set(BOOTSTRAP_CLANG_ENABLE_BOOTSTRAP ON CACHE STRING "") set(BOOTSTRAP_CLANG_BOOTSTRAP_TARGETS clang + package check-all check-llvm check-clang CACHE STRING "") ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [polly] [clang-format] Correctly annotate braces in macros (PR #87953)
tstellar wrote: @owenca Is there a PR for the cherry-pick ? https://github.com/llvm/llvm-project/pull/87953 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CMake][Release] Disable PGO (PR #88465)
tstellar wrote: PR is here: https://github.com/llvm/llvm-project/pull/89000 https://github.com/llvm/llvm-project/pull/88465 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Sema] Mark alias/ifunc targets used and consider mangled names (PR #87130)
https://github.com/tstellar commented: I'm fine with this as long as @AaronBallman approves. https://github.com/llvm/llvm-project/pull/87130 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CMake][Release] Disable PGO (PR #88465)
tstellar wrote: /cherry-pick 0d2bb7f017f13ceae793fab7d83d3e67e8d8d8f8) https://github.com/llvm/llvm-project/pull/88465 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CMake][Release] Disable PGO (PR #88465)
https://github.com/tstellar milestoned https://github.com/llvm/llvm-project/pull/88465 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CMake][Release] Disable PGO (PR #88465)
https://github.com/tstellar closed https://github.com/llvm/llvm-project/pull/88465 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CMake][Release] Disable PGO (PR #88465)
tstellar wrote: > I'm assuming this is a stop-gap, and the plan is to eventually fix the issue > and reenable PGO in the release cache? Yes, I would like to fix this at some point, but not sure when I'll get to it. https://github.com/llvm/llvm-project/pull/88465 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CMake][Release] Disable PGO (PR #88465)
https://github.com/tstellar created https://github.com/llvm/llvm-project/pull/88465 Running the test-release.sh script with PGO enabled causes build errors like: ld.lld: error: Function Import: link error: linking module flags 'ProfileSummary': IDs have conflicting values I believe this a build system bug due to the PGO profile data being generated unconditionally. If you run `ninja check-all` and then `ninja install` like we do in test-release.sh, then the profile data is regenerated during `ninja install` and some of the clang tools which are not test dependencies get build during the ninja install step with different profile data. When these tools link against the LLVM libraries, like libSupport, we end up with these errors. >From 9ebb7efc47a76902fcce078eca4e371d3cf99b68 Mon Sep 17 00:00:00 2001 From: Tom Stellard Date: Fri, 12 Apr 2024 01:10:45 + Subject: [PATCH] [CMake][Release] Disable PGO Running the test-release.sh script with PGO enabled causes build errors like: ld.lld: error: Function Import: link error: linking module flags 'ProfileSummary': IDs have conflicting values I believe this a build system bug due to the PGO profile data being generated unconditionally. If you run `ninja check-all` and then `ninja install` like we do in test-release.sh, then the profile data is regenerated during `ninja install` and some of the clang tools which are not test dependencies get build during the ninja install step with different profile data. When these tools link against the LLVM libraries, like libSupport, we end up with these errors. --- clang/cmake/caches/Release.cmake | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/clang/cmake/caches/Release.cmake b/clang/cmake/caches/Release.cmake index 1ca9138b980731..bd1f688d61a7ea 100644 --- a/clang/cmake/caches/Release.cmake +++ b/clang/cmake/caches/Release.cmake @@ -4,7 +4,7 @@ # General Options set(LLVM_RELEASE_ENABLE_LTO THIN CACHE STRING "") -set(LLVM_RELEASE_ENABLE_PGO ON CACHE BOOL "") +set(LLVM_RELEASE_ENABLE_PGO OFF CACHE BOOL "") set(CMAKE_BUILD_TYPE RELEASE CACHE STRING "") ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Sema] Mark alias/ifunc targets used and consider mangled names (PR #87130)
https://github.com/tstellar requested changes to this pull request. I'm going to NAK this change for now. Given the recent [developments](https://www.openwall.com/lists/oss-security/2024/03/29/4) with the xz project and considering this feature was requested by a user associated with the project, I think we need to be extra careful with this change. I would like to see at least two trusted code owners review and approve this change before it is committed. https://github.com/llvm/llvm-project/pull/87130 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libclc] [libclc] Make CMake messages better fit into LLVM (PR #86945)
https://github.com/tstellar approved this pull request. https://github.com/llvm/llvm-project/pull/86945 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][CodeGen] Allow memcpy replace with trivial auto var init (PR #84230)
tstellar wrote: Do we need to backport this to release/18.x? https://github.com/llvm/llvm-project/pull/84230 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libclc] [libclc] Convert tabs to spaces in CMake (PR #85634)
tstellar wrote: > FWIW I don't think the build bots are actually building `libclc`. > > Locally, at least, it's not sufficient to specify > `LLVM_ENABLE_PROJECTS=libclc` - you _also_ need > `LLVM_EXTERNAL_PROJECTS=libclc`. Even then, it doesn't build for me in-tree, > because it assumes `CMAKE_SOURCE_DIR` is its own top-level directory, which > it isn't as it's `llvm/`. > > I had a patch locally to switch `CMAKE_SOURCE_DIR` to `PROJECT_SOURCE_DIR` > which I think is sufficient to cover both build styles. Should I contribute > this upstream? > > Another problem is that all `libclc` targets are enabled by default, but the > `spirv-mesa3d` and `spirv64-mesa3d` targets both need `llvm-spirv` which I > doubt our buildbots have available. Should those be disabled by default, or > should the buildbots disable them? I'm not aware of any bots building libclc. It would be nice if you could build libclc more easily, it does not fit in with the rest of the projects right now. Any improvements you want to make in this area would be welcome. https://github.com/llvm/llvm-project/pull/85634 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libclc] [libclc] Convert tabs to spaces in CMake (PR #85634)
https://github.com/tstellar approved this pull request. https://github.com/llvm/llvm-project/pull/85634 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] Add missing clang to the monolithic pre-merge build (PR #85354)
https://github.com/tstellar approved this pull request. Good catch. https://github.com/llvm/llvm-project/pull/85354 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][NFC] Regroup declarations in `Sema` (PR #82217)
tstellar wrote: This will make backports more difficult, but I think it's OK. If we wanted to avoid impacting backports, we'd have to wait ~10 weeks to merge this, but that doesn't seem practical. https://github.com/llvm/llvm-project/pull/82217 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] Add 'CLANG_ALLOW_IMPLICIT_RPATH' to enable toolchain use of -rpath (PR #82004)
tstellar wrote: Could we have the upstream default be to install a clang.cfg file in bin/ which has -fimplicit-openmp-rpath (or whatever the hoption is)? https://github.com/llvm/llvm-project/pull/82004 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] Add 'CLANG_ALLOW_IMPLICIT_RPATH' to enable toolchain use of -rpath (PR #82004)
tstellar wrote:
> > > I believe right now the `rtlib-rpath` points to the path
> > > `${CLANG_BINARY}../lib/${HOST_TRIPLE}/`. I think it's definitely
> > > reasonable to not put this on system libraries if that's a solution,
> > > since we can generally assume it's a global installation and already
> > > covered by the user's library path. Does the Fedora policy only disallow
> > > `rpath` on system installs then?
> >
> >
> > Right, any official Fedora binaries we build can't have rpath in them, but
> > users can still use rpath in their own applications if they want.
>
> I'd be okay with that solution. The majority of the issues come from people
> on cluster machines with several conflicting versions of the libraries. The
> only question is how to determine what a system library is. We could possible
> just hardcode a few paths depending on the host triple's operating system.
I'm not a huge fan of trying to auto-detect settings based on the host OS.
What if we just added an option like --exclude-rpath-dir= which would let a
user or a distro specify a list of directories that aren't allowed to be added
as rpath. Now that we have config file support it would be easy for distros to
add a config file with the list of its own system directories.
https://github.com/llvm/llvm-project/pull/82004
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] Add 'CLANG_ALLOW_IMPLICIT_RPATH' to enable toolchain use of -rpath (PR #82004)
tstellar wrote:
>
> I believe right now the `rtlib-rpath` points to the path
> `${CLANG_BINARY}../lib/${HOST_TRIPLE}/`. I think it's definitely reasonable
> to not put this on system libraries if that's a solution, since we can
> generally assume it's a global installation and already covered by the user's
> library path. Does the Fedora policy only disallow `rpath` on system installs
> then?
Right, any official Fedora binaries we build can't have rpath in them, but
users can still use rpath in their own applications if they want.
https://github.com/llvm/llvm-project/pull/82004
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] Add 'CLANG_ALLOW_IMPLICIT_RPATH' to enable toolchain use of -rpath (PR #82004)
tstellar wrote: > We could make this logic more complicated by checking the system > automatically `execute_command(lsb_release)` or something. I think this is too complicated and fragile. If we want to do something specifically to support the distro use case, I think we should do this: https://reviews.llvm.org/D142174 https://github.com/llvm/llvm-project/pull/82004 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] Add 'CLANG_ALLOW_IMPLICIT_RPATH' to enable toolchain use of -rpath (PR #82004)
tstellar wrote: > Does Fedora only use default configurations when building its packages? We try to stick to the defaults as much as possible. Having an implicit rpath by default causes issues when building other RPMs with clang, and typically, if we need to change something in order to build RPMS, we do it by adjusting the global C Flags used for building RPMS rather than patching the compiler. https://github.com/llvm/llvm-project/pull/82004 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] Add 'CLANG_ALLOW_IMPLICIT_RPATH' to enable toolchain use of -rpath (PR #82004)
tstellar wrote: I don't think a CMake option is the right way to go here. For example, I doubt we would actually use this CMake option in Fedora if this patch is committed. Does gcc use rpath for libgomp? https://github.com/llvm/llvm-project/pull/82004 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [CMake][PGO] Build Sema.cpp to generate profdata for PGO builds (PR #77347)
@@ -26,9 +30,23 @@ if(LLVM_BUILD_INSTRUMENTED)
message(STATUS "To enable merging PGO data LLVM_PROFDATA has to point to
llvm-profdata")
else()
add_custom_target(generate-profdata
- COMMAND "${Python3_EXECUTABLE}"
${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py merge ${LLVM_PROFDATA}
${CMAKE_CURRENT_BINARY_DIR}/clang.profdata ${CMAKE_CURRENT_BINARY_DIR}
+ COMMAND "${Python3_EXECUTABLE}"
${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py merge ${LLVM_PROFDATA}
${CMAKE_CURRENT_BINARY_DIR}/clang.profdata ${CMAKE_CURRENT_BINARY_DIR}
${CMAKE_BINARY_DIR}/profiles/
COMMENT "Merging profdata"
DEPENDS generate-profraw)
+if (CLANG_PGO_TRAINING_DATA_SOURCE_DIR)
+ llvm_ExternalProject_Add(generate-profraw-external
${CLANG_PGO_TRAINING_DATA_SOURCE_DIR}
+ USE_TOOLCHAIN EXLUDE_FROM_ALL NO_INSTALL DEPENDS
generate-profraw)
+ add_dependencies(generate-profdata generate-profraw-external)
+else()
+ # Default to compiling a file from clang. This also builds all the
+ # dependencies needed to build this file, like TableGen.
+ set(generate_profraw_clang_sema
tools/clang/lib/Sema/CMakeFiles/obj.clangSema.dir/Sema.cpp.o)
+ llvm_ExternalProject_Add(generate-profraw-clang
${CMAKE_CURRENT_SOURCE_DIR}/../../../llvm
+ USE_TOOLCHAIN EXLUDE_FROM_ALL NO_INSTALL DEPENDS generate-profraw
+ EXTRA_TARGETS generate_profraw_clang_sema
tstellar wrote:
I was compiling just a single file (SemaChecking.cpp).
https://github.com/llvm/llvm-project/pull/77347
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-format] Fix a regression in dumping the config (PR #80628)
tstellar wrote: Tracking the backport request here: #81096 https://github.com/llvm/llvm-project/pull/80628 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[llvm] [clang] [Github] Use building LLVM as perf-training for CI container (PR #80713)
https://github.com/tstellar approved this pull request. https://github.com/llvm/llvm-project/pull/80713 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[llvm] [clang] [Github] Use building LLVM as perf-training for CI container (PR #80713)
@@ -0,0 +1,13 @@ +diff --git a/clang/cmake/caches/BOLT-PGO.cmake b/clang/cmake/caches/BOLT-PGO.cmake +index 1a04ca9a74e5..d092820e4115 100644 +--- a/clang/cmake/caches/BOLT-PGO.cmake b/clang/cmake/caches/BOLT-PGO.cmake +@@ -4,6 +4,8 @@ set(CLANG_BOOTSTRAP_TARGETS + stage2-clang-bolt + stage2-distribution + stage2-install-distribution ++ clang ++ lld tstellar wrote: OK, thanks for the explanation. https://github.com/llvm/llvm-project/pull/80713 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[llvm] [clang] [Github] Use building LLVM as perf-training for CI container (PR #80713)
@@ -0,0 +1,13 @@ +diff --git a/clang/cmake/caches/BOLT-PGO.cmake b/clang/cmake/caches/BOLT-PGO.cmake +index 1a04ca9a74e5..d092820e4115 100644 +--- a/clang/cmake/caches/BOLT-PGO.cmake b/clang/cmake/caches/BOLT-PGO.cmake +@@ -4,6 +4,8 @@ set(CLANG_BOOTSTRAP_TARGETS + stage2-clang-bolt + stage2-distribution + stage2-install-distribution ++ clang ++ lld tstellar wrote: Do you need this because of the way you have split the stages? If you were to to just run `ninja stage2-clang-bolt` from the start would it still be building a lot of unnecessary targets prior to generating the profile data? I'm mainly wondering if this is a change that would benefit everyone using the BOLT-PGO cache. https://github.com/llvm/llvm-project/pull/80713 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [Github] Use building LLVM as perf-training for CI container (PR #80713)
@@ -0,0 +1,13 @@ +diff --git a/clang/cmake/caches/BOLT-PGO.cmake b/clang/cmake/caches/BOLT-PGO.cmake +index 1a04ca9a74e5..d092820e4115 100644 +--- a/clang/cmake/caches/BOLT-PGO.cmake b/clang/cmake/caches/BOLT-PGO.cmake +@@ -4,6 +4,8 @@ set(CLANG_BOOTSTRAP_TARGETS + stage2-clang-bolt + stage2-distribution + stage2-install-distribution ++ clang ++ lld tstellar wrote: Why is this needed? https://github.com/llvm/llvm-project/pull/80713 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [llvm] [CMake][PGO] Add option for using an external project to generate profile data (PR #78879)
https://github.com/tstellar closed https://github.com/llvm/llvm-project/pull/78879 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [llvm] [CMake][PGO] Add option for using an external project to generate profile data (PR #78879)
@@ -2,7 +2,7 @@ set(CMAKE_BUILD_TYPE RELEASE CACHE STRING "") set(CLANG_ENABLE_BOOTSTRAP ON CACHE BOOL "") set(LLVM_ENABLE_PROJECTS "clang;lld" CACHE STRING "") -set(LLVM_ENABLE_RUNTIMES "compiler-rt;libcxx;libcxxabi" CACHE STRING "") +set(LLVM_ENABLE_RUNTIMES "compiler-rt;libcxx;libcxxabi;libunwind" CACHE STRING "") tstellar wrote: @aaupov How does this look now? https://github.com/llvm/llvm-project/pull/78879 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [llvm] [CMake][PGO] Add option for using an external project to generate profile data (PR #78879)
https://github.com/tstellar updated
https://github.com/llvm/llvm-project/pull/78879
>From 0719f49ecc6dd69ae4698c3e84dbf175a1bf2ed3 Mon Sep 17 00:00:00 2001
From: Tom Stellard
Date: Sun, 21 Jan 2024 00:25:47 +
Subject: [PATCH 1/4] [CMake][PGO] Add libunwind to list of stage1 runtimes
This fixes the build since 8f90e6937a1fac80873bb2dab5f382c82ba1ba4e
which made libcxxabi use llvm's libunwind by default.
---
clang/cmake/caches/PGO.cmake | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/clang/cmake/caches/PGO.cmake b/clang/cmake/caches/PGO.cmake
index e1d0585e453f8..15bc755d110d1 100644
--- a/clang/cmake/caches/PGO.cmake
+++ b/clang/cmake/caches/PGO.cmake
@@ -2,7 +2,7 @@ set(CMAKE_BUILD_TYPE RELEASE CACHE STRING "")
set(CLANG_ENABLE_BOOTSTRAP ON CACHE BOOL "")
set(LLVM_ENABLE_PROJECTS "clang;lld" CACHE STRING "")
-set(LLVM_ENABLE_RUNTIMES "compiler-rt;libcxx;libcxxabi" CACHE STRING "")
+set(LLVM_ENABLE_RUNTIMES "compiler-rt;libcxx;libcxxabi;libunwind" CACHE STRING
"")
set(LLVM_TARGETS_TO_BUILD Native CACHE STRING "")
set(BOOTSTRAP_LLVM_BUILD_INSTRUMENTED ON CACHE BOOL "")
>From 5c602233ef4e54e850f6c8a17c25968bc706b898 Mon Sep 17 00:00:00 2001
From: Tom Stellard
Date: Sat, 6 Jan 2024 07:46:01 +
Subject: [PATCH 2/4] [CMake][PGO] Add option for using an external project to
generate profile data.
The new CLANG_PGO_TRAINING_DATA_SOURCE_DIR allows users to specify a CMake
project to use for generating the profile data.
For example, to use the llvm-test-suite to generate profile data you
would do:
$ cmake -G Ninja -B build -S llvm -C /clang/cmake/caches/PGO.cmake \
-DBOOTSTRAP_CLANG_PGO_TRAINING_DATA_SOURCE_DIR= \
-DBOOTSTRAP_CLANG_PERF_TRAINING_DEPS=runtimes
---
clang/utils/perf-training/CMakeLists.txt | 13 +++--
clang/utils/perf-training/perf-helper.py | 16 +---
llvm/docs/AdvancedBuilds.rst | 23 +++
3 files changed, 43 insertions(+), 9 deletions(-)
diff --git a/clang/utils/perf-training/CMakeLists.txt
b/clang/utils/perf-training/CMakeLists.txt
index c6d51863fb1b5..f9d673b2e92e7 100644
--- a/clang/utils/perf-training/CMakeLists.txt
+++ b/clang/utils/perf-training/CMakeLists.txt
@@ -1,6 +1,10 @@
+include(LLVMExternalProjectUtils)
+
set(CLANG_PGO_TRAINING_DATA "${CMAKE_CURRENT_SOURCE_DIR}" CACHE PATH
"The path to a lit testsuite containing samples for PGO and order file
generation"
)
+set(CLANG_PGO_TRAINING_DATA_SOURCE_DIR OFF CACHE STRING "Path to source
directory containing cmake project with source files to use for generating pgo
data")
+set(CLANG_PERF_TRAINING_DEPS "" CACHE STRING "Extra dependencies needed to
build the PGO training data.")
if(LLVM_BUILD_INSTRUMENTED)
configure_lit_site_cfg(
@@ -15,7 +19,7 @@ if(LLVM_BUILD_INSTRUMENTED)
)
add_custom_target(clear-profraw
-COMMAND "${Python3_EXECUTABLE}" ${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py
clean ${CMAKE_CURRENT_BINARY_DIR} profraw
+COMMAND "${Python3_EXECUTABLE}" ${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py
clean ${CMAKE_CURRENT_BINARY_DIR} ${CMAKE_BINARY_DIR}/profiles/ profraw
COMMENT "Clearing old profraw data")
if(NOT LLVM_PROFDATA)
@@ -26,9 +30,14 @@ if(LLVM_BUILD_INSTRUMENTED)
message(STATUS "To enable merging PGO data LLVM_PROFDATA has to point to
llvm-profdata")
else()
add_custom_target(generate-profdata
- COMMAND "${Python3_EXECUTABLE}"
${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py merge ${LLVM_PROFDATA}
${CMAKE_CURRENT_BINARY_DIR}/clang.profdata ${CMAKE_CURRENT_BINARY_DIR}
+ COMMAND "${Python3_EXECUTABLE}"
${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py merge ${LLVM_PROFDATA}
${CMAKE_CURRENT_BINARY_DIR}/clang.profdata ${CMAKE_CURRENT_BINARY_DIR}
${CMAKE_BINARY_DIR}/profiles/
COMMENT "Merging profdata"
DEPENDS generate-profraw)
+if (CLANG_PGO_TRAINING_DATA_SOURCE_DIR)
+ llvm_ExternalProject_Add(generate-profraw-external
${CLANG_PGO_TRAINING_DATA_SOURCE_DIR}
+ USE_TOOLCHAIN EXLUDE_FROM_ALL NO_INSTALL DEPENDS
generate-profraw)
+ add_dependencies(generate-profdata generate-profraw-external)
+endif()
endif()
endif()
diff --git a/clang/utils/perf-training/perf-helper.py
b/clang/utils/perf-training/perf-helper.py
index 99d6ab6ef..844aa274f049a 100644
--- a/clang/utils/perf-training/perf-helper.py
+++ b/clang/utils/perf-training/perf-helper.py
@@ -30,26 +30,28 @@ def findFilesWithExtension(path, extension):
def clean(args):
-if len(args) != 2:
+if len(args) < 2:
print(
-"Usage: %s clean \n" % __file__
+"Usage: %s clean \n" % __file__
+ "\tRemoves all files with extension from ."
)
return 1
-for filename in findFilesWithExtension(args[0], args[1]):
-os.remove(filename)
+for path in args[1:-1]:
+for filename in findFilesWithExtension(path, args[-1]):
+os.remove(filename)
return 0
def
[clang] [llvm] [CMake][PGO] Add option for using an external project to generate profile data (PR #78879)
@@ -11,11 +15,11 @@ if(LLVM_BUILD_INSTRUMENTED)
add_lit_testsuite(generate-profraw "Generating clang PGO data"
${CMAKE_CURRENT_BINARY_DIR}/pgo-data/
EXCLUDE_FROM_CHECK_ALL
-DEPENDS clang clear-profraw ${CLANG_PERF_TRAINING_DEPS}
+DEPENDS clang clear-profraw ${CLANG_PGO_TRAINING_DEPS}
)
add_custom_target(clear-profraw
-COMMAND "${Python3_EXECUTABLE}" ${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py
clean ${CMAKE_CURRENT_BINARY_DIR} profraw
+COMMAND "${Python3_EXECUTABLE}" ${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py
clean ${CMAKE_CURRENT_BINARY_DIR} ${CMAKE_BINARY_DIR}/profiles/ profraw
tstellar wrote:
@aaupov That's the directory where clang will write it's profiles to by default.
https://github.com/llvm/llvm-project/pull/78879
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[llvm] [clang] [SystemZ][z/OS] This change adds support for the PPA2 section in zOS (PR #68926)
@@ -0,0 +1,31 @@ +; RUN: llc -mtriple s390x-ibm-zos -mcpu=z15 -asm-verbose=true < %s | FileCheck %s +; REQUIRES: systemz-registered-target + +; CHECK:.section".ppa2" +; CHECK: @@PPA2: +; CHECK:.byte 3 +; CHECK:.byte 231 +; CHECK:.byte 34 +; CHECK:.byte 4 +; CHECK:.long CELQSTRT-@@PPA2 +; CHECK:.long 0 +; CHECK:.long @@DVS-@@PPA2 +; CHECK:.long 0 +; CHECK:.byte 129 +; CHECK:.byte 0 +; CHECK:.short 0 +; CHECK: @@DVS: +; CHECK:.ascii "\361\371\367\360\360\361\360\361\360\360\360\360\360\360" +; CHECK:.short 0 +; CHECK:.quad @@PPA2-CELQSTRT * A(PPA2-CELQSTRT) +; CHECK: @@PPA1_void_test_0: +; CHECK:.long @@PPA2-@@PPA1_void_test_0 * Offset to PPA2 +; CHECK:.section"B_IDRL" +; CHECK:.byte 0 +; CHECK:.byte 3 +; CHECK:.short 30 +; CHECK:.ascii "\323\323\345\324@@\361\370\360\360\361\371\367\360\360\361\360\361\360\360\360\360\360\360\360\360" tstellar wrote: Hi, Based on 4236d56141be3a421d9e7fe8bb7f1ba1663ec97a, it appears that this test encodes the llvm version into the test. Is there some way to change this test so it does not container the llvm version in it. It's not practical to have to update this every time there is a release. https://github.com/llvm/llvm-project/pull/68926 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [CMake][PGO] Add option for using an external project to generate profile data (PR #78879)
https://github.com/tstellar updated
https://github.com/llvm/llvm-project/pull/78879
>From 0719f49ecc6dd69ae4698c3e84dbf175a1bf2ed3 Mon Sep 17 00:00:00 2001
From: Tom Stellard
Date: Sun, 21 Jan 2024 00:25:47 +
Subject: [PATCH 1/4] [CMake][PGO] Add libunwind to list of stage1 runtimes
This fixes the build since 8f90e6937a1fac80873bb2dab5f382c82ba1ba4e
which made libcxxabi use llvm's libunwind by default.
---
clang/cmake/caches/PGO.cmake | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/clang/cmake/caches/PGO.cmake b/clang/cmake/caches/PGO.cmake
index e1d0585e453f825..15bc755d110d19a 100644
--- a/clang/cmake/caches/PGO.cmake
+++ b/clang/cmake/caches/PGO.cmake
@@ -2,7 +2,7 @@ set(CMAKE_BUILD_TYPE RELEASE CACHE STRING "")
set(CLANG_ENABLE_BOOTSTRAP ON CACHE BOOL "")
set(LLVM_ENABLE_PROJECTS "clang;lld" CACHE STRING "")
-set(LLVM_ENABLE_RUNTIMES "compiler-rt;libcxx;libcxxabi" CACHE STRING "")
+set(LLVM_ENABLE_RUNTIMES "compiler-rt;libcxx;libcxxabi;libunwind" CACHE STRING
"")
set(LLVM_TARGETS_TO_BUILD Native CACHE STRING "")
set(BOOTSTRAP_LLVM_BUILD_INSTRUMENTED ON CACHE BOOL "")
>From 5c602233ef4e54e850f6c8a17c25968bc706b898 Mon Sep 17 00:00:00 2001
From: Tom Stellard
Date: Sat, 6 Jan 2024 07:46:01 +
Subject: [PATCH 2/4] [CMake][PGO] Add option for using an external project to
generate profile data.
The new CLANG_PGO_TRAINING_DATA_SOURCE_DIR allows users to specify a CMake
project to use for generating the profile data.
For example, to use the llvm-test-suite to generate profile data you
would do:
$ cmake -G Ninja -B build -S llvm -C /clang/cmake/caches/PGO.cmake \
-DBOOTSTRAP_CLANG_PGO_TRAINING_DATA_SOURCE_DIR= \
-DBOOTSTRAP_CLANG_PERF_TRAINING_DEPS=runtimes
---
clang/utils/perf-training/CMakeLists.txt | 13 +++--
clang/utils/perf-training/perf-helper.py | 16 +---
llvm/docs/AdvancedBuilds.rst | 23 +++
3 files changed, 43 insertions(+), 9 deletions(-)
diff --git a/clang/utils/perf-training/CMakeLists.txt
b/clang/utils/perf-training/CMakeLists.txt
index c6d51863fb1b5c2..f9d673b2e92e775 100644
--- a/clang/utils/perf-training/CMakeLists.txt
+++ b/clang/utils/perf-training/CMakeLists.txt
@@ -1,6 +1,10 @@
+include(LLVMExternalProjectUtils)
+
set(CLANG_PGO_TRAINING_DATA "${CMAKE_CURRENT_SOURCE_DIR}" CACHE PATH
"The path to a lit testsuite containing samples for PGO and order file
generation"
)
+set(CLANG_PGO_TRAINING_DATA_SOURCE_DIR OFF CACHE STRING "Path to source
directory containing cmake project with source files to use for generating pgo
data")
+set(CLANG_PERF_TRAINING_DEPS "" CACHE STRING "Extra dependencies needed to
build the PGO training data.")
if(LLVM_BUILD_INSTRUMENTED)
configure_lit_site_cfg(
@@ -15,7 +19,7 @@ if(LLVM_BUILD_INSTRUMENTED)
)
add_custom_target(clear-profraw
-COMMAND "${Python3_EXECUTABLE}" ${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py
clean ${CMAKE_CURRENT_BINARY_DIR} profraw
+COMMAND "${Python3_EXECUTABLE}" ${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py
clean ${CMAKE_CURRENT_BINARY_DIR} ${CMAKE_BINARY_DIR}/profiles/ profraw
COMMENT "Clearing old profraw data")
if(NOT LLVM_PROFDATA)
@@ -26,9 +30,14 @@ if(LLVM_BUILD_INSTRUMENTED)
message(STATUS "To enable merging PGO data LLVM_PROFDATA has to point to
llvm-profdata")
else()
add_custom_target(generate-profdata
- COMMAND "${Python3_EXECUTABLE}"
${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py merge ${LLVM_PROFDATA}
${CMAKE_CURRENT_BINARY_DIR}/clang.profdata ${CMAKE_CURRENT_BINARY_DIR}
+ COMMAND "${Python3_EXECUTABLE}"
${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py merge ${LLVM_PROFDATA}
${CMAKE_CURRENT_BINARY_DIR}/clang.profdata ${CMAKE_CURRENT_BINARY_DIR}
${CMAKE_BINARY_DIR}/profiles/
COMMENT "Merging profdata"
DEPENDS generate-profraw)
+if (CLANG_PGO_TRAINING_DATA_SOURCE_DIR)
+ llvm_ExternalProject_Add(generate-profraw-external
${CLANG_PGO_TRAINING_DATA_SOURCE_DIR}
+ USE_TOOLCHAIN EXLUDE_FROM_ALL NO_INSTALL DEPENDS
generate-profraw)
+ add_dependencies(generate-profdata generate-profraw-external)
+endif()
endif()
endif()
diff --git a/clang/utils/perf-training/perf-helper.py
b/clang/utils/perf-training/perf-helper.py
index 99d6ab6ef08..844aa274f049aaa 100644
--- a/clang/utils/perf-training/perf-helper.py
+++ b/clang/utils/perf-training/perf-helper.py
@@ -30,26 +30,28 @@ def findFilesWithExtension(path, extension):
def clean(args):
-if len(args) != 2:
+if len(args) < 2:
print(
-"Usage: %s clean \n" % __file__
+"Usage: %s clean \n" % __file__
+ "\tRemoves all files with extension from ."
)
return 1
-for filename in findFilesWithExtension(args[0], args[1]):
-os.remove(filename)
+for path in args[1:-1]:
+for filename in findFilesWithExtension(path, args[-1]):
+os.remove(filename)
return 0
def
[clang] [llvm] [CMake][PGO] Add option for using an external project to generate profile data (PR #78879)
https://github.com/tstellar edited https://github.com/llvm/llvm-project/pull/78879 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [CMake][Release] Add option for enabling PGO to release cache file. (PR #78823)
https://github.com/tstellar closed https://github.com/llvm/llvm-project/pull/78823 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [CMake][PGO] Add option for using an external project to generate profile data (PR #78879)
https://github.com/tstellar updated
https://github.com/llvm/llvm-project/pull/78879
>From 0719f49ecc6dd69ae4698c3e84dbf175a1bf2ed3 Mon Sep 17 00:00:00 2001
From: Tom Stellard
Date: Sun, 21 Jan 2024 00:25:47 +
Subject: [PATCH 1/3] [CMake][PGO] Add libunwind to list of stage1 runtimes
This fixes the build since 8f90e6937a1fac80873bb2dab5f382c82ba1ba4e
which made libcxxabi use llvm's libunwind by default.
---
clang/cmake/caches/PGO.cmake | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/clang/cmake/caches/PGO.cmake b/clang/cmake/caches/PGO.cmake
index e1d0585e453f825..15bc755d110d19a 100644
--- a/clang/cmake/caches/PGO.cmake
+++ b/clang/cmake/caches/PGO.cmake
@@ -2,7 +2,7 @@ set(CMAKE_BUILD_TYPE RELEASE CACHE STRING "")
set(CLANG_ENABLE_BOOTSTRAP ON CACHE BOOL "")
set(LLVM_ENABLE_PROJECTS "clang;lld" CACHE STRING "")
-set(LLVM_ENABLE_RUNTIMES "compiler-rt;libcxx;libcxxabi" CACHE STRING "")
+set(LLVM_ENABLE_RUNTIMES "compiler-rt;libcxx;libcxxabi;libunwind" CACHE STRING
"")
set(LLVM_TARGETS_TO_BUILD Native CACHE STRING "")
set(BOOTSTRAP_LLVM_BUILD_INSTRUMENTED ON CACHE BOOL "")
>From 5c602233ef4e54e850f6c8a17c25968bc706b898 Mon Sep 17 00:00:00 2001
From: Tom Stellard
Date: Sat, 6 Jan 2024 07:46:01 +
Subject: [PATCH 2/3] [CMake][PGO] Add option for using an external project to
generate profile data.
The new CLANG_PGO_TRAINING_DATA_SOURCE_DIR allows users to specify a CMake
project to use for generating the profile data.
For example, to use the llvm-test-suite to generate profile data you
would do:
$ cmake -G Ninja -B build -S llvm -C /clang/cmake/caches/PGO.cmake \
-DBOOTSTRAP_CLANG_PGO_TRAINING_DATA_SOURCE_DIR= \
-DBOOTSTRAP_CLANG_PERF_TRAINING_DEPS=runtimes
---
clang/utils/perf-training/CMakeLists.txt | 13 +++--
clang/utils/perf-training/perf-helper.py | 16 +---
llvm/docs/AdvancedBuilds.rst | 23 +++
3 files changed, 43 insertions(+), 9 deletions(-)
diff --git a/clang/utils/perf-training/CMakeLists.txt
b/clang/utils/perf-training/CMakeLists.txt
index c6d51863fb1b5c2..f9d673b2e92e775 100644
--- a/clang/utils/perf-training/CMakeLists.txt
+++ b/clang/utils/perf-training/CMakeLists.txt
@@ -1,6 +1,10 @@
+include(LLVMExternalProjectUtils)
+
set(CLANG_PGO_TRAINING_DATA "${CMAKE_CURRENT_SOURCE_DIR}" CACHE PATH
"The path to a lit testsuite containing samples for PGO and order file
generation"
)
+set(CLANG_PGO_TRAINING_DATA_SOURCE_DIR OFF CACHE STRING "Path to source
directory containing cmake project with source files to use for generating pgo
data")
+set(CLANG_PERF_TRAINING_DEPS "" CACHE STRING "Extra dependencies needed to
build the PGO training data.")
if(LLVM_BUILD_INSTRUMENTED)
configure_lit_site_cfg(
@@ -15,7 +19,7 @@ if(LLVM_BUILD_INSTRUMENTED)
)
add_custom_target(clear-profraw
-COMMAND "${Python3_EXECUTABLE}" ${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py
clean ${CMAKE_CURRENT_BINARY_DIR} profraw
+COMMAND "${Python3_EXECUTABLE}" ${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py
clean ${CMAKE_CURRENT_BINARY_DIR} ${CMAKE_BINARY_DIR}/profiles/ profraw
COMMENT "Clearing old profraw data")
if(NOT LLVM_PROFDATA)
@@ -26,9 +30,14 @@ if(LLVM_BUILD_INSTRUMENTED)
message(STATUS "To enable merging PGO data LLVM_PROFDATA has to point to
llvm-profdata")
else()
add_custom_target(generate-profdata
- COMMAND "${Python3_EXECUTABLE}"
${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py merge ${LLVM_PROFDATA}
${CMAKE_CURRENT_BINARY_DIR}/clang.profdata ${CMAKE_CURRENT_BINARY_DIR}
+ COMMAND "${Python3_EXECUTABLE}"
${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py merge ${LLVM_PROFDATA}
${CMAKE_CURRENT_BINARY_DIR}/clang.profdata ${CMAKE_CURRENT_BINARY_DIR}
${CMAKE_BINARY_DIR}/profiles/
COMMENT "Merging profdata"
DEPENDS generate-profraw)
+if (CLANG_PGO_TRAINING_DATA_SOURCE_DIR)
+ llvm_ExternalProject_Add(generate-profraw-external
${CLANG_PGO_TRAINING_DATA_SOURCE_DIR}
+ USE_TOOLCHAIN EXLUDE_FROM_ALL NO_INSTALL DEPENDS
generate-profraw)
+ add_dependencies(generate-profdata generate-profraw-external)
+endif()
endif()
endif()
diff --git a/clang/utils/perf-training/perf-helper.py
b/clang/utils/perf-training/perf-helper.py
index 99d6ab6ef08..844aa274f049aaa 100644
--- a/clang/utils/perf-training/perf-helper.py
+++ b/clang/utils/perf-training/perf-helper.py
@@ -30,26 +30,28 @@ def findFilesWithExtension(path, extension):
def clean(args):
-if len(args) != 2:
+if len(args) < 2:
print(
-"Usage: %s clean \n" % __file__
+"Usage: %s clean \n" % __file__
+ "\tRemoves all files with extension from ."
)
return 1
-for filename in findFilesWithExtension(args[0], args[1]):
-os.remove(filename)
+for path in args[1:-1]:
+for filename in findFilesWithExtension(path, args[-1]):
+os.remove(filename)
return 0
def
[clang] [llvm] [CMake][PGO] Add option for using an external project to generate profile data (PR #78879)
@@ -15,7 +19,7 @@ if(LLVM_BUILD_INSTRUMENTED) ) tstellar wrote: @petrhosek CLANG_PERF_TRAINING_DEPS was an existing variable that's used here. I think it was meant to be added to cache files, but I added it to CMakeLists.txt file here so that it could be passed on the command line without modifying the cache files. https://github.com/llvm/llvm-project/pull/78879 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[llvm] [clang] [CMake][PGO] Build Sema.cpp to generate profdata for PGO builds (PR #77347)
tstellar wrote: I split the new configuration option out into a separate PR: #78879, because it seems useful regardless of what the default is. We can continue to discuss the best default on this PR. https://github.com/llvm/llvm-project/pull/77347 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[llvm] [clang] [CMake][PGO] Add option for using an external project to generate profile data (PR #78879)
https://github.com/tstellar created
https://github.com/llvm/llvm-project/pull/78879
The new CLANG_PGO_TRAINING_DATA_SOURCE_DIR allows users to specify a CMake
project to use for generating the profile data. For example, to use the
llvm-test-suite to generate profile data you would do:
$ cmake -G Ninja -B build -S llvm -C /clang/cmake/caches/PGO.cmake \
-DBOOTSTRAP_CLANG_PGO_TRAINING_DATA_SOURCE_DIR= \
-DBOOTSTRAP_CLANG_PERF_TRAINING_DEPS=runtimes
>From 0719f49ecc6dd69ae4698c3e84dbf175a1bf2ed3 Mon Sep 17 00:00:00 2001
From: Tom Stellard
Date: Sun, 21 Jan 2024 00:25:47 +
Subject: [PATCH 1/2] [CMake][PGO] Add libunwind to list of stage1 runtimes
This fixes the build since 8f90e6937a1fac80873bb2dab5f382c82ba1ba4e
which made libcxxabi use llvm's libunwind by default.
---
clang/cmake/caches/PGO.cmake | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/clang/cmake/caches/PGO.cmake b/clang/cmake/caches/PGO.cmake
index e1d0585e453f825..15bc755d110d19a 100644
--- a/clang/cmake/caches/PGO.cmake
+++ b/clang/cmake/caches/PGO.cmake
@@ -2,7 +2,7 @@ set(CMAKE_BUILD_TYPE RELEASE CACHE STRING "")
set(CLANG_ENABLE_BOOTSTRAP ON CACHE BOOL "")
set(LLVM_ENABLE_PROJECTS "clang;lld" CACHE STRING "")
-set(LLVM_ENABLE_RUNTIMES "compiler-rt;libcxx;libcxxabi" CACHE STRING "")
+set(LLVM_ENABLE_RUNTIMES "compiler-rt;libcxx;libcxxabi;libunwind" CACHE STRING
"")
set(LLVM_TARGETS_TO_BUILD Native CACHE STRING "")
set(BOOTSTRAP_LLVM_BUILD_INSTRUMENTED ON CACHE BOOL "")
>From 5c602233ef4e54e850f6c8a17c25968bc706b898 Mon Sep 17 00:00:00 2001
From: Tom Stellard
Date: Sat, 6 Jan 2024 07:46:01 +
Subject: [PATCH 2/2] [CMake][PGO] Add option for using an external project to
generate profile data.
The new CLANG_PGO_TRAINING_DATA_SOURCE_DIR allows users to specify a CMake
project to use for generating the profile data.
For example, to use the llvm-test-suite to generate profile data you
would do:
$ cmake -G Ninja -B build -S llvm -C /clang/cmake/caches/PGO.cmake \
-DBOOTSTRAP_CLANG_PGO_TRAINING_DATA_SOURCE_DIR= \
-DBOOTSTRAP_CLANG_PERF_TRAINING_DEPS=runtimes
---
clang/utils/perf-training/CMakeLists.txt | 13 +++--
clang/utils/perf-training/perf-helper.py | 16 +---
llvm/docs/AdvancedBuilds.rst | 23 +++
3 files changed, 43 insertions(+), 9 deletions(-)
diff --git a/clang/utils/perf-training/CMakeLists.txt
b/clang/utils/perf-training/CMakeLists.txt
index c6d51863fb1b5c2..f9d673b2e92e775 100644
--- a/clang/utils/perf-training/CMakeLists.txt
+++ b/clang/utils/perf-training/CMakeLists.txt
@@ -1,6 +1,10 @@
+include(LLVMExternalProjectUtils)
+
set(CLANG_PGO_TRAINING_DATA "${CMAKE_CURRENT_SOURCE_DIR}" CACHE PATH
"The path to a lit testsuite containing samples for PGO and order file
generation"
)
+set(CLANG_PGO_TRAINING_DATA_SOURCE_DIR OFF CACHE STRING "Path to source
directory containing cmake project with source files to use for generating pgo
data")
+set(CLANG_PERF_TRAINING_DEPS "" CACHE STRING "Extra dependencies needed to
build the PGO training data.")
if(LLVM_BUILD_INSTRUMENTED)
configure_lit_site_cfg(
@@ -15,7 +19,7 @@ if(LLVM_BUILD_INSTRUMENTED)
)
add_custom_target(clear-profraw
-COMMAND "${Python3_EXECUTABLE}" ${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py
clean ${CMAKE_CURRENT_BINARY_DIR} profraw
+COMMAND "${Python3_EXECUTABLE}" ${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py
clean ${CMAKE_CURRENT_BINARY_DIR} ${CMAKE_BINARY_DIR}/profiles/ profraw
COMMENT "Clearing old profraw data")
if(NOT LLVM_PROFDATA)
@@ -26,9 +30,14 @@ if(LLVM_BUILD_INSTRUMENTED)
message(STATUS "To enable merging PGO data LLVM_PROFDATA has to point to
llvm-profdata")
else()
add_custom_target(generate-profdata
- COMMAND "${Python3_EXECUTABLE}"
${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py merge ${LLVM_PROFDATA}
${CMAKE_CURRENT_BINARY_DIR}/clang.profdata ${CMAKE_CURRENT_BINARY_DIR}
+ COMMAND "${Python3_EXECUTABLE}"
${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py merge ${LLVM_PROFDATA}
${CMAKE_CURRENT_BINARY_DIR}/clang.profdata ${CMAKE_CURRENT_BINARY_DIR}
${CMAKE_BINARY_DIR}/profiles/
COMMENT "Merging profdata"
DEPENDS generate-profraw)
+if (CLANG_PGO_TRAINING_DATA_SOURCE_DIR)
+ llvm_ExternalProject_Add(generate-profraw-external
${CLANG_PGO_TRAINING_DATA_SOURCE_DIR}
+ USE_TOOLCHAIN EXLUDE_FROM_ALL NO_INSTALL DEPENDS
generate-profraw)
+ add_dependencies(generate-profdata generate-profraw-external)
+endif()
endif()
endif()
diff --git a/clang/utils/perf-training/perf-helper.py
b/clang/utils/perf-training/perf-helper.py
index 99d6ab6ef08..844aa274f049aaa 100644
--- a/clang/utils/perf-training/perf-helper.py
+++ b/clang/utils/perf-training/perf-helper.py
@@ -30,26 +30,28 @@ def findFilesWithExtension(path, extension):
def clean(args):
-if len(args) != 2:
+if len(args) < 2:
print(
-"Usage: %s clean
[clang] [CMake][PGO] Add libunwind to list of stage1 runtimes (PR #78869)
https://github.com/tstellar created https://github.com/llvm/llvm-project/pull/78869 This fixes the build since 8f90e6937a1fac80873bb2dab5f382c82ba1ba4e which made libcxxabi use llvm's libunwind by default. >From 0719f49ecc6dd69ae4698c3e84dbf175a1bf2ed3 Mon Sep 17 00:00:00 2001 From: Tom Stellard Date: Sun, 21 Jan 2024 00:25:47 + Subject: [PATCH] [CMake][PGO] Add libunwind to list of stage1 runtimes This fixes the build since 8f90e6937a1fac80873bb2dab5f382c82ba1ba4e which made libcxxabi use llvm's libunwind by default. --- clang/cmake/caches/PGO.cmake | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/clang/cmake/caches/PGO.cmake b/clang/cmake/caches/PGO.cmake index e1d0585e453f82..15bc755d110d19 100644 --- a/clang/cmake/caches/PGO.cmake +++ b/clang/cmake/caches/PGO.cmake @@ -2,7 +2,7 @@ set(CMAKE_BUILD_TYPE RELEASE CACHE STRING "") set(CLANG_ENABLE_BOOTSTRAP ON CACHE BOOL "") set(LLVM_ENABLE_PROJECTS "clang;lld" CACHE STRING "") -set(LLVM_ENABLE_RUNTIMES "compiler-rt;libcxx;libcxxabi" CACHE STRING "") +set(LLVM_ENABLE_RUNTIMES "compiler-rt;libcxx;libcxxabi;libunwind" CACHE STRING "") set(LLVM_TARGETS_TO_BUILD Native CACHE STRING "") set(BOOTSTRAP_LLVM_BUILD_INSTRUMENTED ON CACHE BOOL "") ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [CMake][Release] Add option for enabling PGO to release cache file. (PR #78823)
https://github.com/tstellar updated
https://github.com/llvm/llvm-project/pull/78823
>From b23e23f862bec32e42fa7aa96da1fe0c4ed38a54 Mon Sep 17 00:00:00 2001
From: Tom Stellard
Date: Sat, 6 Jan 2024 06:44:32 +
Subject: [PATCH 1/2] [CMake][Release] Add option for enabling PGO to release
cache file.
The option is LLVM_RELEASE_ENABLE_PGO and it's turned on by default.
---
clang/cmake/caches/Release.cmake | 73 +++---
llvm/utils/release/test-release.sh | 4 +-
2 files changed, 59 insertions(+), 18 deletions(-)
diff --git a/clang/cmake/caches/Release.cmake b/clang/cmake/caches/Release.cmake
index a7b9a8d0e29f88..0d114c3734a82d 100644
--- a/clang/cmake/caches/Release.cmake
+++ b/clang/cmake/caches/Release.cmake
@@ -4,27 +4,53 @@
# General Options
set(LLVM_RELEASE_ENABLE_LTO THIN CACHE STRING "")
+set(LLVM_RELEASE_ENABLE_PGO ON CACHE BOOL "")
set(CMAKE_BUILD_TYPE RELEASE CACHE STRING "")
# Stage 1 Bootstrap Setup
set(CLANG_ENABLE_BOOTSTRAP ON CACHE BOOL "")
-set(CLANG_BOOTSTRAP_TARGETS
- clang
- check-all
- check-llvm
- check-clang
- test-suite
- stage3
- stage3-clang
- stage3-check-all
- stage3-check-llvm
- stage3-check-clang
- stage3-install
- stage3-test-suite CACHE STRING "")
+if (LLVM_RELEASE_ENABLE_PGO)
+ set(CLANG_BOOTSTRAP_TARGETS
+generate-profdata
+stage2
+stage2-clang
+stage2-distribution
+stage2-install
+stage2-install-distribution
+stage2-install-distribution-toolchain
+stage2-check-all
+stage2-check-llvm
+stage2-check-clang
+stage2-test-suite CACHE STRING "")
+else()
+ set(CLANG_BOOTSTRAP_TARGETS
+clang
+check-all
+check-llvm
+check-clang
+test-suite
+stage3
+stage3-clang
+stage3-check-all
+stage3-check-llvm
+stage3-check-clang
+stage3-install
+stage3-test-suite CACHE STRING "")
+endif()
# Stage 1 Options
-set(LLVM_ENABLE_PROJECTS "clang" CACHE STRING "")
+set(STAGE1_PROJECTS "clang")
+set(STAGE1_RUNTIMES "")
+
+if (LLVM_RELEASE_ENABLE_PGO)
+ list(APPEND STAGE1_PROJECTS "lld")
+ list(APPEND STAGE1_RUNTIMES "compiler-rt")
+endif()
+
+set(LLVM_ENABLE_RUNTIMES ${STAGE1_RUNTIMES} CACHE STRING "")
+set(LLVM_ENABLE_PROJECTS ${STAGE1_PROJECTS} CACHE STRING "")
+
set(LLVM_TARGETS_TO_BUILD Native CACHE STRING "")
# Stage 2 Bootstrap Setup
@@ -37,11 +63,26 @@ set(BOOTSTRAP_CLANG_BOOTSTRAP_TARGETS
# Stage 2 Options
set(STAGE2_PROJECTS "clang")
-if (LLVM_RELEASE_ENABLE_LTO)
+set(STAGE2_RUNTIMES "")
+
+if (LLVM_RELEASE_ENABLE_LTO OR LLVM_RELEASE_ENABLE_PGO)
list(APPEND STAGE2_PROJECTS "lld")
endif()
+
+if (LLVM_RELEASE_ENABLE_PGO)
+ set(BOOTSTRAP_LLVM_BUILD_INSTRUMENTED ON CACHE BOOL "")
+ list(APPEND STAGE2_RUNTIMES "compiler-rt")
+ set(BOOTSTRAP_LLVM_ENABLE_LTO ${LLVM_RELEASE_ENABLE_LTO})
+ if (LLVM_RELEASE_ENABLE_LTO)
+set(BOOTSTRAP_LLVM_ENABLE_LLD ON CACHE BOOL "")
+ endif()
+endif()
+
set(BOOTSTRAP_LLVM_ENABLE_PROJECTS ${STAGE2_PROJECTS} CACHE STRING "")
-set(BOOTSTRAP_LLVM_TARGETS_TO_BUILD Native CACHE STRING "")
+set(BOOTSTRAP_LLVM_ENABLE_RUNTIMES ${STAGE2_RUNTIMES} CACHE STRING "")
+if (NOT LLVM_RELEASE_ENABLE_PGO)
+ set(BOOTSTRAP_LLVM_TARGETS_TO_BUILD Native CACHE STRING "")
+endif()
# Stage 3 Options
set(BOOTSTRAP_BOOTSTRAP_LLVM_ENABLE_RUNTIMES
"compiler-rt;libcxx;libcxxabi;libunwind" CACHE STRING "")
diff --git a/llvm/utils/release/test-release.sh
b/llvm/utils/release/test-release.sh
index 544d4bfdd799ce..5b1945df47d24a 100755
--- a/llvm/utils/release/test-release.sh
+++ b/llvm/utils/release/test-release.sh
@@ -359,11 +359,11 @@ function build_with_cmake_cache() {
$ExtraConfigureFlags
2>&1 | tee $LogDir/llvm.configure-$Flavor.log
- ${MAKE} $J_ARG $Verbose -C $CMakeBuildDir stage3-check-all \
+ ${MAKE} $J_ARG $Verbose -C $CMakeBuildDir stage2-check-all \
2>&1 | tee $LogDir/llvm.make-$Flavor.log > $redir
DESTDIR="${InstallDir}" \
- ${MAKE} -C $CMakeBuildDir stage3-install \
+ ${MAKE} -C $CMakeBuildDir stage2-install \
2>&1 | tee $LogDir/llvm.install-$Flavor.log > $redir
mkdir -p $BuildDir/Release
>From db6cc2ea33fc19f1359cbf38ff10059ac3aa1832 Mon Sep 17 00:00:00 2001
From: Tom Stellard
Date: Sat, 20 Jan 2024 17:10:29 -0800
Subject: [PATCH 2/2] Update clang/cmake/caches/Release.cmake
Co-authored-by: Petr Hosek
---
clang/cmake/caches/Release.cmake | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/clang/cmake/caches/Release.cmake b/clang/cmake/caches/Release.cmake
index 0d114c3734a82d..1ca9138b980731 100644
--- a/clang/cmake/caches/Release.cmake
+++ b/clang/cmake/caches/Release.cmake
@@ -70,7 +70,7 @@ if (LLVM_RELEASE_ENABLE_LTO OR LLVM_RELEASE_ENABLE_PGO)
endif()
if (LLVM_RELEASE_ENABLE_PGO)
- set(BOOTSTRAP_LLVM_BUILD_INSTRUMENTED ON CACHE BOOL "")
+ set(BOOTSTRAP_LLVM_BUILD_INSTRUMENTED IR CACHE STRING "")
list(APPEND STAGE2_RUNTIMES "compiler-rt")
set(BOOTSTRAP_LLVM_ENABLE_LTO ${LLVM_RELEASE_ENABLE_LTO})
if
[clang] [llvm] [workflows] Split pr-code-format into two parts to make it more secure (PR #78216)
https://github.com/tstellar updated
https://github.com/llvm/llvm-project/pull/78216
>From 035d4129ff02b776df53bfe149ce4af4af6072c4 Mon Sep 17 00:00:00 2001
From: Konrad Kleine
Date: Thu, 24 Mar 2022 09:44:21 +0100
Subject: [PATCH 01/10] Produce DWARF4 by default
Have a look at the following commit to see when the move from DWARF 4 to 5
first happened upstream:
https://github.com/llvm/llvm-project/commit/d3b26dea16108c427b19b5480c9edc76edf8f5b4?diff=unified
---
clang/lib/Driver/ToolChain.cpp | 4 +---
clang/test/CodeGen/dwarf-version.c | 8
clang/test/Driver/as-options.s | 4 ++--
clang/test/Driver/cl-options.c | 2 +-
clang/test/Driver/clang-g-opts.c | 2 +-
clang/test/Driver/ve-toolchain.c | 2 +-
clang/test/Driver/ve-toolchain.cpp | 2 +-
7 files changed, 11 insertions(+), 13 deletions(-)
diff --git a/clang/lib/Driver/ToolChain.cpp b/clang/lib/Driver/ToolChain.cpp
index 96a57927339a97..56c7d0e8db02c9 100644
--- a/clang/lib/Driver/ToolChain.cpp
+++ b/clang/lib/Driver/ToolChain.cpp
@@ -428,9 +428,7 @@ ToolChain::getDefaultUnwindTableLevel(const ArgList )
const {
}
unsigned ToolChain::GetDefaultDwarfVersion() const {
- // TODO: Remove the RISC-V special case when R_RISCV_SET_ULEB128 linker
- // support becomes more widely available.
- return getTriple().isRISCV() ? 4 : 5;
+ return 4;
}
Tool *ToolChain::getClang() const {
diff --git a/clang/test/CodeGen/dwarf-version.c
b/clang/test/CodeGen/dwarf-version.c
index e63316ace69c87..3d68b06c58ff8b 100644
--- a/clang/test/CodeGen/dwarf-version.c
+++ b/clang/test/CodeGen/dwarf-version.c
@@ -2,10 +2,10 @@
// RUN: %clang -target x86_64-linux-gnu -gdwarf-3 -S -emit-llvm -o - %s |
FileCheck %s --check-prefix=VER3
// RUN: %clang -target x86_64-linux-gnu -gdwarf-4 -S -emit-llvm -o - %s |
FileCheck %s --check-prefix=VER4
// RUN: %clang -target x86_64-linux-gnu -gdwarf-5 -S -emit-llvm -o - %s |
FileCheck %s --check-prefix=VER5
-// RUN: %clang -target x86_64-linux-gnu -g -S -emit-llvm -o - %s | FileCheck
%s --check-prefix=VER5
-// RUN: %clang -target x86_64-linux-gnu -gdwarf -S -emit-llvm -o - %s |
FileCheck %s --check-prefix=VER5
-// RUN: %clang --target=i386-pc-solaris -g -S -emit-llvm -o - %s | FileCheck
%s --check-prefix=VER5
-// RUN: %clang --target=i386-pc-solaris -gdwarf -S -emit-llvm -o - %s |
FileCheck %s --check-prefix=VER5
+// RUN: %clang -target x86_64-linux-gnu -g -S -emit-llvm -o - %s | FileCheck
%s --check-prefix=VER4
+// RUN: %clang -target x86_64-linux-gnu -gdwarf -S -emit-llvm -o - %s |
FileCheck %s --check-prefix=VER4
+// RUN: %clang --target=i386-pc-solaris -g -S -emit-llvm -o - %s | FileCheck
%s --check-prefix=VER4
+// RUN: %clang --target=i386-pc-solaris -gdwarf -S -emit-llvm -o - %s |
FileCheck %s --check-prefix=VER4
// The -isysroot is used as a hack to avoid LIT messing with the SDKROOT
// environment variable which indirecty overrides the version in the target
diff --git a/clang/test/Driver/as-options.s b/clang/test/Driver/as-options.s
index 73d002c7ef7ed3..71d55f7fd53761 100644
--- a/clang/test/Driver/as-options.s
+++ b/clang/test/Driver/as-options.s
@@ -122,7 +122,7 @@
// RUN: FileCheck --check-prefix=DEBUG %s
// RUN: %clang --target=aarch64-linux-gnu -fno-integrated-as -g0 -g %s -###
2>&1 | \
// RUN: FileCheck --check-prefix=DEBUG %s
-// DEBUG: "-g" "-gdwarf-5"
+// DEBUG: "-g" "-gdwarf-4"
// RUN: %clang --target=aarch64-linux-gnu -fno-integrated-as -g -g0 %s -###
2>&1 | \
// RUN: FileCheck --check-prefix=NODEBUG %s
// RUN: %clang --target=aarch64-linux-gnu -fno-integrated-as -gdwarf-5 -g0 %s
-### 2>&1 | \
@@ -141,7 +141,7 @@
// RUN: %clang --target=aarch64-linux-gnu -fno-integrated-as -gdwarf-2 %s -###
2>&1 | \
// RUN: FileCheck --check-prefix=GDWARF2 %s
// RUN: %clang --target=aarch64-linux-gnu -fno-integrated-as -gdwarf %s -###
2>&1 | \
-// RUN: FileCheck --check-prefix=GDWARF5 %s
+// RUN: FileCheck --check-prefix=GDWARF4 %s
// RUN: %clang --target=aarch64-linux-gnu -fno-integrated-as -gdwarf-5 %s -###
2>&1 | \
// RUN: FileCheck --check-prefix=GDWARF5 %s
diff --git a/clang/test/Driver/cl-options.c b/clang/test/Driver/cl-options.c
index 5b6dfe308a76ea..4da65272a1b0df 100644
--- a/clang/test/Driver/cl-options.c
+++ b/clang/test/Driver/cl-options.c
@@ -571,7 +571,7 @@
// RUN: %clang_cl -gdwarf /Z7 /c -### -- %s 2>&1 | FileCheck
-check-prefix=Z7_gdwarf %s
// Z7_gdwarf-NOT: "-gcodeview"
// Z7_gdwarf: "-debug-info-kind=constructor"
-// Z7_gdwarf: "-dwarf-version=
+// Z7_gdwarf: "-dwarf-version=4
// RUN: %clang_cl /ZH:MD5 /c -### -- %s 2>&1 | FileCheck -check-prefix=ZH_MD5
%s
// ZH_MD5: "-gsrc-hash=md5"
diff --git a/clang/test/Driver/clang-g-opts.c b/clang/test/Driver/clang-g-opts.c
index b73602a155b009..b0cf6467425340 100644
--- a/clang/test/Driver/clang-g-opts.c
+++ b/clang/test/Driver/clang-g-opts.c
@@ -36,7 +36,7 @@
// CHECK-WITHOUT-G-NOT: -debug-info-kind
// CHECK-WITH-G: "-debug-info-kind=constructor"
-// CHECK-WITH-G:
[clang] Add a "don't override" mapping for -fvisibility-from-dllstorageclass (PR #74629)
tstellar wrote: This commit broke the [ llvm-x86_64-debian-dylib bot](https://lab.llvm.org/buildbot/#/builders/196/builds/42821) https://github.com/llvm/llvm-project/pull/74629 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [CMake][Release] Add option for enabling PGO to release cache file. (PR #78823)
https://github.com/tstellar created
https://github.com/llvm/llvm-project/pull/78823
The option is LLVM_RELEASE_ENABLE_PGO and it's turned on by default.
>From b23e23f862bec32e42fa7aa96da1fe0c4ed38a54 Mon Sep 17 00:00:00 2001
From: Tom Stellard
Date: Sat, 6 Jan 2024 06:44:32 +
Subject: [PATCH] [CMake][Release] Add option for enabling PGO to release cache
file.
The option is LLVM_RELEASE_ENABLE_PGO and it's turned on by default.
---
clang/cmake/caches/Release.cmake | 73 +++---
llvm/utils/release/test-release.sh | 4 +-
2 files changed, 59 insertions(+), 18 deletions(-)
diff --git a/clang/cmake/caches/Release.cmake b/clang/cmake/caches/Release.cmake
index a7b9a8d0e29f88f..0d114c3734a82d3 100644
--- a/clang/cmake/caches/Release.cmake
+++ b/clang/cmake/caches/Release.cmake
@@ -4,27 +4,53 @@
# General Options
set(LLVM_RELEASE_ENABLE_LTO THIN CACHE STRING "")
+set(LLVM_RELEASE_ENABLE_PGO ON CACHE BOOL "")
set(CMAKE_BUILD_TYPE RELEASE CACHE STRING "")
# Stage 1 Bootstrap Setup
set(CLANG_ENABLE_BOOTSTRAP ON CACHE BOOL "")
-set(CLANG_BOOTSTRAP_TARGETS
- clang
- check-all
- check-llvm
- check-clang
- test-suite
- stage3
- stage3-clang
- stage3-check-all
- stage3-check-llvm
- stage3-check-clang
- stage3-install
- stage3-test-suite CACHE STRING "")
+if (LLVM_RELEASE_ENABLE_PGO)
+ set(CLANG_BOOTSTRAP_TARGETS
+generate-profdata
+stage2
+stage2-clang
+stage2-distribution
+stage2-install
+stage2-install-distribution
+stage2-install-distribution-toolchain
+stage2-check-all
+stage2-check-llvm
+stage2-check-clang
+stage2-test-suite CACHE STRING "")
+else()
+ set(CLANG_BOOTSTRAP_TARGETS
+clang
+check-all
+check-llvm
+check-clang
+test-suite
+stage3
+stage3-clang
+stage3-check-all
+stage3-check-llvm
+stage3-check-clang
+stage3-install
+stage3-test-suite CACHE STRING "")
+endif()
# Stage 1 Options
-set(LLVM_ENABLE_PROJECTS "clang" CACHE STRING "")
+set(STAGE1_PROJECTS "clang")
+set(STAGE1_RUNTIMES "")
+
+if (LLVM_RELEASE_ENABLE_PGO)
+ list(APPEND STAGE1_PROJECTS "lld")
+ list(APPEND STAGE1_RUNTIMES "compiler-rt")
+endif()
+
+set(LLVM_ENABLE_RUNTIMES ${STAGE1_RUNTIMES} CACHE STRING "")
+set(LLVM_ENABLE_PROJECTS ${STAGE1_PROJECTS} CACHE STRING "")
+
set(LLVM_TARGETS_TO_BUILD Native CACHE STRING "")
# Stage 2 Bootstrap Setup
@@ -37,11 +63,26 @@ set(BOOTSTRAP_CLANG_BOOTSTRAP_TARGETS
# Stage 2 Options
set(STAGE2_PROJECTS "clang")
-if (LLVM_RELEASE_ENABLE_LTO)
+set(STAGE2_RUNTIMES "")
+
+if (LLVM_RELEASE_ENABLE_LTO OR LLVM_RELEASE_ENABLE_PGO)
list(APPEND STAGE2_PROJECTS "lld")
endif()
+
+if (LLVM_RELEASE_ENABLE_PGO)
+ set(BOOTSTRAP_LLVM_BUILD_INSTRUMENTED ON CACHE BOOL "")
+ list(APPEND STAGE2_RUNTIMES "compiler-rt")
+ set(BOOTSTRAP_LLVM_ENABLE_LTO ${LLVM_RELEASE_ENABLE_LTO})
+ if (LLVM_RELEASE_ENABLE_LTO)
+set(BOOTSTRAP_LLVM_ENABLE_LLD ON CACHE BOOL "")
+ endif()
+endif()
+
set(BOOTSTRAP_LLVM_ENABLE_PROJECTS ${STAGE2_PROJECTS} CACHE STRING "")
-set(BOOTSTRAP_LLVM_TARGETS_TO_BUILD Native CACHE STRING "")
+set(BOOTSTRAP_LLVM_ENABLE_RUNTIMES ${STAGE2_RUNTIMES} CACHE STRING "")
+if (NOT LLVM_RELEASE_ENABLE_PGO)
+ set(BOOTSTRAP_LLVM_TARGETS_TO_BUILD Native CACHE STRING "")
+endif()
# Stage 3 Options
set(BOOTSTRAP_BOOTSTRAP_LLVM_ENABLE_RUNTIMES
"compiler-rt;libcxx;libcxxabi;libunwind" CACHE STRING "")
diff --git a/llvm/utils/release/test-release.sh
b/llvm/utils/release/test-release.sh
index 544d4bfdd799ce8..5b1945df47d24a7 100755
--- a/llvm/utils/release/test-release.sh
+++ b/llvm/utils/release/test-release.sh
@@ -359,11 +359,11 @@ function build_with_cmake_cache() {
$ExtraConfigureFlags
2>&1 | tee $LogDir/llvm.configure-$Flavor.log
- ${MAKE} $J_ARG $Verbose -C $CMakeBuildDir stage3-check-all \
+ ${MAKE} $J_ARG $Verbose -C $CMakeBuildDir stage2-check-all \
2>&1 | tee $LogDir/llvm.make-$Flavor.log > $redir
DESTDIR="${InstallDir}" \
- ${MAKE} -C $CMakeBuildDir stage3-install \
+ ${MAKE} -C $CMakeBuildDir stage2-install \
2>&1 | tee $LogDir/llvm.install-$Flavor.log > $redir
mkdir -p $BuildDir/Release
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang-tools-extra] [flang] [clang] [llvm] [compiler-rt] workflows: Refactor release-tasks.yml (PR #69523)
https://github.com/tstellar closed https://github.com/llvm/llvm-project/pull/69523 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[llvm] [clang] [CMake][PGO] Build Sema.cpp to generate profdata for PGO builds (PR #77347)
@@ -26,9 +30,23 @@ if(LLVM_BUILD_INSTRUMENTED)
message(STATUS "To enable merging PGO data LLVM_PROFDATA has to point to
llvm-profdata")
else()
add_custom_target(generate-profdata
- COMMAND "${Python3_EXECUTABLE}"
${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py merge ${LLVM_PROFDATA}
${CMAKE_CURRENT_BINARY_DIR}/clang.profdata ${CMAKE_CURRENT_BINARY_DIR}
+ COMMAND "${Python3_EXECUTABLE}"
${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py merge ${LLVM_PROFDATA}
${CMAKE_CURRENT_BINARY_DIR}/clang.profdata ${CMAKE_CURRENT_BINARY_DIR}
${CMAKE_BINARY_DIR}/profiles/
COMMENT "Merging profdata"
DEPENDS generate-profraw)
+if (CLANG_PGO_TRAINING_DATA_SOURCE_DIR)
+ llvm_ExternalProject_Add(generate-profraw-external
${CLANG_PGO_TRAINING_DATA_SOURCE_DIR}
+ USE_TOOLCHAIN EXLUDE_FROM_ALL NO_INSTALL DEPENDS
generate-profraw)
+ add_dependencies(generate-profdata generate-profraw-external)
+else()
+ # Default to compiling a file from clang. This also builds all the
+ # dependencies needed to build this file, like TableGen.
+ set(generate_profraw_clang_sema
tools/clang/lib/Sema/CMakeFiles/obj.clangSema.dir/Sema.cpp.o)
+ llvm_ExternalProject_Add(generate-profraw-clang
${CMAKE_CURRENT_SOURCE_DIR}/../../../llvm
+ USE_TOOLCHAIN EXLUDE_FROM_ALL NO_INSTALL DEPENDS generate-profraw
+ EXTRA_TARGETS generate_profraw_clang_sema
tstellar wrote:
> The idea I'd like explore is using libc++ (and perhaps also libc) test suite
> for training. It consists of self-contained test programs which should
> sufficiently exercise various aspects of C/C++ frontend.
I've updated the patch to use the check-cxx target to generate the profile
data. The gains (~20%) are less than with Sema.cpp (~34%) but still pretty
good. The only issue is that the profile data comes from building libcxx as
well, so it's not just from the test suite.
It may be possible to get test data from just running the test suite, but that
might be a lot more complicated to set up.
https://github.com/llvm/llvm-project/pull/77347
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[llvm] [clang] [CMake][PGO] Build Sema.cpp to generate profdata for PGO builds (PR #77347)
https://github.com/tstellar updated
https://github.com/llvm/llvm-project/pull/77347
>From 127e2ae83f33843cfb9c5cca314afa2fc9844239 Mon Sep 17 00:00:00 2001
From: Tom Stellard
Date: Sat, 6 Jan 2024 07:46:01 +
Subject: [PATCH 1/7] [CMake][PGO] Use check-clang target to generate profdata
for PGO builds
When doing a multi-stage PGO build of clang, run the check-clang and
check-llvm targets using the instrumented clang and use that profile
data for building the final stage2 clang. This is what is recommended
by our official documentation:
https://llvm.org/docs/HowToBuildWithPGO.html#building-clang-with-pgo
I benchmarked this change by compiling the SemaChecking.cpp file from
clang. Using check-clang/check-llvm to generate the profile data gives a 25%
speedup
in the PGO+LTO stage2 clang when compared to the stage1 clang (no-LTO).
Prior to this change, I was only seeing ~5% speedup when comparing the
stage2 and stage1 builds.
---
clang/utils/perf-training/CMakeLists.txt | 6 +++---
clang/utils/perf-training/perf-helper.py | 16 +---
2 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/clang/utils/perf-training/CMakeLists.txt
b/clang/utils/perf-training/CMakeLists.txt
index c6d51863fb1b5c..95ff8115aa538b 100644
--- a/clang/utils/perf-training/CMakeLists.txt
+++ b/clang/utils/perf-training/CMakeLists.txt
@@ -15,7 +15,7 @@ if(LLVM_BUILD_INSTRUMENTED)
)
add_custom_target(clear-profraw
-COMMAND "${Python3_EXECUTABLE}" ${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py
clean ${CMAKE_CURRENT_BINARY_DIR} profraw
+COMMAND "${Python3_EXECUTABLE}" ${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py
clean ${CMAKE_CURRENT_BINARY_DIR} ${CMAKE_BINARY_DIR}/profiles/ profraw
COMMENT "Clearing old profraw data")
if(NOT LLVM_PROFDATA)
@@ -26,9 +26,9 @@ if(LLVM_BUILD_INSTRUMENTED)
message(STATUS "To enable merging PGO data LLVM_PROFDATA has to point to
llvm-profdata")
else()
add_custom_target(generate-profdata
- COMMAND "${Python3_EXECUTABLE}"
${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py merge ${LLVM_PROFDATA}
${CMAKE_CURRENT_BINARY_DIR}/clang.profdata ${CMAKE_CURRENT_BINARY_DIR}
+ COMMAND "${Python3_EXECUTABLE}"
${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py merge ${LLVM_PROFDATA}
${CMAKE_CURRENT_BINARY_DIR}/clang.profdata ${CMAKE_CURRENT_BINARY_DIR}
${CMAKE_BINARY_DIR}/profiles/
COMMENT "Merging profdata"
- DEPENDS generate-profraw)
+ DEPENDS generate-profraw check-clang check-llvm)
endif()
endif()
diff --git a/clang/utils/perf-training/perf-helper.py
b/clang/utils/perf-training/perf-helper.py
index 99d6ab6ef0..bd8f74c9c2e129 100644
--- a/clang/utils/perf-training/perf-helper.py
+++ b/clang/utils/perf-training/perf-helper.py
@@ -30,26 +30,28 @@ def findFilesWithExtension(path, extension):
def clean(args):
-if len(args) != 2:
+if len(args) < 2:
print(
-"Usage: %s clean \n" % __file__
+"Usage: %s clean \n" % __file__
+ "\tRemoves all files with extension from ."
)
return 1
-for filename in findFilesWithExtension(args[0], args[1]):
-os.remove(filename)
+for path in args[1:-1]:
+ for filename in findFilesWithExtension(path, args[-1]):
+ os.remove(filename)
return 0
def merge(args):
-if len(args) != 3:
+if len(args) < 3:
print(
-"Usage: %s merge \n" % __file__
+"Usage: %s merge \n" % __file__
+ "\tMerges all profraw files from path into output."
)
return 1
cmd = [args[0], "merge", "-o", args[1]]
-cmd.extend(findFilesWithExtension(args[2], "profraw"))
+for i in range(2, len(args)):
+ cmd.extend(findFilesWithExtension(args[i], "profraw"))
subprocess.check_call(cmd)
return 0
>From 4f7734584af3aa9a18bde17349ceccbef3658c53 Mon Sep 17 00:00:00 2001
From: Tom Stellard
Date: Mon, 8 Jan 2024 18:07:31 +
Subject: [PATCH 2/7] Fix python formatting
---
clang/utils/perf-training/perf-helper.py | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/clang/utils/perf-training/perf-helper.py
b/clang/utils/perf-training/perf-helper.py
index bd8f74c9c2e129..844aa274f049aa 100644
--- a/clang/utils/perf-training/perf-helper.py
+++ b/clang/utils/perf-training/perf-helper.py
@@ -37,8 +37,8 @@ def clean(args):
)
return 1
for path in args[1:-1]:
- for filename in findFilesWithExtension(path, args[-1]):
- os.remove(filename)
+for filename in findFilesWithExtension(path, args[-1]):
+os.remove(filename)
return 0
@@ -51,7 +51,7 @@ def merge(args):
return 1
cmd = [args[0], "merge", "-o", args[1]]
for i in range(2, len(args)):
- cmd.extend(findFilesWithExtension(args[i], "profraw"))
+cmd.extend(findFilesWithExtension(args[i], "profraw"))
subprocess.check_call(cmd)
return 0
>From
[clang-tools-extra] [llvm] [clang] [compiler-rt] [flang] workflows: Refactor release-tasks.yml (PR #69523)
https://github.com/tstellar updated
https://github.com/llvm/llvm-project/pull/69523
>From 6a7f298f403e0e454644f3d945242120f8b2b321 Mon Sep 17 00:00:00 2001
From: Tom Stellard
Date: Wed, 18 Oct 2023 04:56:28 -0700
Subject: [PATCH 1/7] workflows: Refactor release-tasks.yml
* Split out the lit release job and the documentation build jobs into their
own workflow files. This makes it possible to manually run these jobs
via workflow_dispatch.
* Improve tag/user validation and ensure it gets run for each release
task.
---
.github/workflows/release-binaries.yml| 51 ---
.github/workflows/release-documentation.yml | 84 +++
.github/workflows/release-doxygen.yml | 62
.github/workflows/release-lit.yml | 74 +
.github/workflows/release-tasks.yml | 140 ++
.../workflows/set-release-binary-outputs.sh | 18 +--
llvm/utils/release/github-upload-release.py | 22 ++-
7 files changed, 321 insertions(+), 130 deletions(-)
create mode 100644 .github/workflows/release-documentation.yml
create mode 100644 .github/workflows/release-doxygen.yml
create mode 100644 .github/workflows/release-lit.yml
diff --git a/.github/workflows/release-binaries.yml
b/.github/workflows/release-binaries.yml
index 75d4f419ab1fdc..d8b732413d2bf6 100644
--- a/.github/workflows/release-binaries.yml
+++ b/.github/workflows/release-binaries.yml
@@ -1,20 +1,29 @@
name: Release Binaries
on:
- push:
-tags:
- - 'llvmorg-*'
workflow_dispatch:
inputs:
+ release-version:
+description: 'Release Version'
+required: true
+type: string
upload:
description: 'Upload binaries to the release page'
required: true
-default: true
+default: false
type: boolean
- tag:
-description: 'Tag to build'
+
+ workflow_call:
+inputs:
+ release-version:
+description: 'Release Version'
required: true
type: string
+ upload:
+description: 'Upload binaries to the release page'
+required: true
+default: false
+type: boolean
permissions:
contents: read # Default everything to read-only
@@ -23,21 +32,26 @@ jobs:
prepare:
name: Prepare to build binaries
runs-on: ubuntu-22.04
-if: github.repository == 'llvm/llvm-project'
outputs:
- release-version: ${{ steps.validate-tag.outputs.release-version }}
- release: ${{ steps.validate-tag.outputs.release }}
- build-dir: ${{ steps.validate-tag.outputs.build-dir }}
- rc-flags: ${{ steps.validate-tag.outputs.rc-flags }}
- ref: ${{ steps.validate-tag.outputs.ref }}
- upload: ${{ steps.validate-tag.outputs.upload }}
+ release-version: ${{ steps.vars.outputs.release-version }}
+ release: ${{ steps.vars.outputs.release }}
+ build-dir: ${{ steps.vars.outputs.build-dir }}
+ rc-flags: ${{ steps.vars.outputs.rc-flags }}
+ ref: ${{ steps.vars.outputs.ref }}
+ upload: ${{ steps.vars.outputs.upload }}
steps:
- name: Checkout LLVM
uses: actions/checkout@v4
-- name: Validate and parse tag
- id: validate-tag
+- name: Check Permissions
+ env:
+GITHUB_TOKEN: ${{ github.token }}
+ run: |
+./llvm/utils/release/./github-upload-release.py --token
"$GITHUB_TOKEN" --user ${{ github.actor }} check-permissions
+
+- name: Collect Variables
+ id: vars
# In order for the test-release.sh script to run correctly, the LLVM
# source needs to be at the following location relative to the build dir:
# | X.Y.Z-rcN | ./rcN/llvm-project
@@ -47,15 +61,12 @@ jobs:
# | X.Y.Z-rcN | -rc N -test-asserts
# | X.Y.Z | -final
run: |
-tag="${{ github.ref_name }}"
-trimmed=$(echo ${{ inputs.tag }} | xargs)
-[[ "$trimmed" != "" ]] && tag="$trimmed"
if [ -n "${{ inputs.upload }}" ]; then
upload="${{ inputs.upload }}"
else
- upload="true"
+ upload="false"
fi
-bash .github/workflows/set-release-binary-outputs.sh "${{ github.actor
}}" "$tag" "$upload"
+bash .github/workflows/set-release-binary-outputs.sh "${{
inputs.release-version }}" "$upload"
# Try to get around the 6 hour timeout by first running a job to fill
# the build cache.
diff --git a/.github/workflows/release-documentation.yml
b/.github/workflows/release-documentation.yml
new file mode 100644
index 00..832570ed6fe93f
--- /dev/null
+++ b/.github/workflows/release-documentation.yml
@@ -0,0 +1,84 @@
+name: Release Documentation
+
+permissions:
+ contents: read
+
+on:
+ workflow_dispatch:
+inputs:
+ release-version:
+description: 'Release Version'
+required: true
+type: string
+ upload:
+description: 'Upload documentation'
+required: false
+type: boolean
+
+ workflow_call:
+
[flang] [clang] [llvm] [clang-tools-extra] [compiler-rt] workflows: Refactor release-tasks.yml (PR #69523)
https://github.com/tstellar updated
https://github.com/llvm/llvm-project/pull/69523
>From 6a7f298f403e0e454644f3d945242120f8b2b321 Mon Sep 17 00:00:00 2001
From: Tom Stellard
Date: Wed, 18 Oct 2023 04:56:28 -0700
Subject: [PATCH 1/6] workflows: Refactor release-tasks.yml
* Split out the lit release job and the documentation build jobs into their
own workflow files. This makes it possible to manually run these jobs
via workflow_dispatch.
* Improve tag/user validation and ensure it gets run for each release
task.
---
.github/workflows/release-binaries.yml| 51 ---
.github/workflows/release-documentation.yml | 84 +++
.github/workflows/release-doxygen.yml | 62
.github/workflows/release-lit.yml | 74 +
.github/workflows/release-tasks.yml | 140 ++
.../workflows/set-release-binary-outputs.sh | 18 +--
llvm/utils/release/github-upload-release.py | 22 ++-
7 files changed, 321 insertions(+), 130 deletions(-)
create mode 100644 .github/workflows/release-documentation.yml
create mode 100644 .github/workflows/release-doxygen.yml
create mode 100644 .github/workflows/release-lit.yml
diff --git a/.github/workflows/release-binaries.yml
b/.github/workflows/release-binaries.yml
index 75d4f419ab1fdc..d8b732413d2bf6 100644
--- a/.github/workflows/release-binaries.yml
+++ b/.github/workflows/release-binaries.yml
@@ -1,20 +1,29 @@
name: Release Binaries
on:
- push:
-tags:
- - 'llvmorg-*'
workflow_dispatch:
inputs:
+ release-version:
+description: 'Release Version'
+required: true
+type: string
upload:
description: 'Upload binaries to the release page'
required: true
-default: true
+default: false
type: boolean
- tag:
-description: 'Tag to build'
+
+ workflow_call:
+inputs:
+ release-version:
+description: 'Release Version'
required: true
type: string
+ upload:
+description: 'Upload binaries to the release page'
+required: true
+default: false
+type: boolean
permissions:
contents: read # Default everything to read-only
@@ -23,21 +32,26 @@ jobs:
prepare:
name: Prepare to build binaries
runs-on: ubuntu-22.04
-if: github.repository == 'llvm/llvm-project'
outputs:
- release-version: ${{ steps.validate-tag.outputs.release-version }}
- release: ${{ steps.validate-tag.outputs.release }}
- build-dir: ${{ steps.validate-tag.outputs.build-dir }}
- rc-flags: ${{ steps.validate-tag.outputs.rc-flags }}
- ref: ${{ steps.validate-tag.outputs.ref }}
- upload: ${{ steps.validate-tag.outputs.upload }}
+ release-version: ${{ steps.vars.outputs.release-version }}
+ release: ${{ steps.vars.outputs.release }}
+ build-dir: ${{ steps.vars.outputs.build-dir }}
+ rc-flags: ${{ steps.vars.outputs.rc-flags }}
+ ref: ${{ steps.vars.outputs.ref }}
+ upload: ${{ steps.vars.outputs.upload }}
steps:
- name: Checkout LLVM
uses: actions/checkout@v4
-- name: Validate and parse tag
- id: validate-tag
+- name: Check Permissions
+ env:
+GITHUB_TOKEN: ${{ github.token }}
+ run: |
+./llvm/utils/release/./github-upload-release.py --token
"$GITHUB_TOKEN" --user ${{ github.actor }} check-permissions
+
+- name: Collect Variables
+ id: vars
# In order for the test-release.sh script to run correctly, the LLVM
# source needs to be at the following location relative to the build dir:
# | X.Y.Z-rcN | ./rcN/llvm-project
@@ -47,15 +61,12 @@ jobs:
# | X.Y.Z-rcN | -rc N -test-asserts
# | X.Y.Z | -final
run: |
-tag="${{ github.ref_name }}"
-trimmed=$(echo ${{ inputs.tag }} | xargs)
-[[ "$trimmed" != "" ]] && tag="$trimmed"
if [ -n "${{ inputs.upload }}" ]; then
upload="${{ inputs.upload }}"
else
- upload="true"
+ upload="false"
fi
-bash .github/workflows/set-release-binary-outputs.sh "${{ github.actor
}}" "$tag" "$upload"
+bash .github/workflows/set-release-binary-outputs.sh "${{
inputs.release-version }}" "$upload"
# Try to get around the 6 hour timeout by first running a job to fill
# the build cache.
diff --git a/.github/workflows/release-documentation.yml
b/.github/workflows/release-documentation.yml
new file mode 100644
index 00..832570ed6fe93f
--- /dev/null
+++ b/.github/workflows/release-documentation.yml
@@ -0,0 +1,84 @@
+name: Release Documentation
+
+permissions:
+ contents: read
+
+on:
+ workflow_dispatch:
+inputs:
+ release-version:
+description: 'Release Version'
+required: true
+type: string
+ upload:
+description: 'Upload documentation'
+required: false
+type: boolean
+
+ workflow_call:
+
[llvm] [compiler-rt] [flang] [clang] [clang-tools-extra] workflows: Refactor release-tasks.yml (PR #69523)
https://github.com/tstellar updated
https://github.com/llvm/llvm-project/pull/69523
>From 6a7f298f403e0e454644f3d945242120f8b2b321 Mon Sep 17 00:00:00 2001
From: Tom Stellard
Date: Wed, 18 Oct 2023 04:56:28 -0700
Subject: [PATCH 1/5] workflows: Refactor release-tasks.yml
* Split out the lit release job and the documentation build jobs into their
own workflow files. This makes it possible to manually run these jobs
via workflow_dispatch.
* Improve tag/user validation and ensure it gets run for each release
task.
---
.github/workflows/release-binaries.yml| 51 ---
.github/workflows/release-documentation.yml | 84 +++
.github/workflows/release-doxygen.yml | 62
.github/workflows/release-lit.yml | 74 +
.github/workflows/release-tasks.yml | 140 ++
.../workflows/set-release-binary-outputs.sh | 18 +--
llvm/utils/release/github-upload-release.py | 22 ++-
7 files changed, 321 insertions(+), 130 deletions(-)
create mode 100644 .github/workflows/release-documentation.yml
create mode 100644 .github/workflows/release-doxygen.yml
create mode 100644 .github/workflows/release-lit.yml
diff --git a/.github/workflows/release-binaries.yml
b/.github/workflows/release-binaries.yml
index 75d4f419ab1fdc..d8b732413d2bf6 100644
--- a/.github/workflows/release-binaries.yml
+++ b/.github/workflows/release-binaries.yml
@@ -1,20 +1,29 @@
name: Release Binaries
on:
- push:
-tags:
- - 'llvmorg-*'
workflow_dispatch:
inputs:
+ release-version:
+description: 'Release Version'
+required: true
+type: string
upload:
description: 'Upload binaries to the release page'
required: true
-default: true
+default: false
type: boolean
- tag:
-description: 'Tag to build'
+
+ workflow_call:
+inputs:
+ release-version:
+description: 'Release Version'
required: true
type: string
+ upload:
+description: 'Upload binaries to the release page'
+required: true
+default: false
+type: boolean
permissions:
contents: read # Default everything to read-only
@@ -23,21 +32,26 @@ jobs:
prepare:
name: Prepare to build binaries
runs-on: ubuntu-22.04
-if: github.repository == 'llvm/llvm-project'
outputs:
- release-version: ${{ steps.validate-tag.outputs.release-version }}
- release: ${{ steps.validate-tag.outputs.release }}
- build-dir: ${{ steps.validate-tag.outputs.build-dir }}
- rc-flags: ${{ steps.validate-tag.outputs.rc-flags }}
- ref: ${{ steps.validate-tag.outputs.ref }}
- upload: ${{ steps.validate-tag.outputs.upload }}
+ release-version: ${{ steps.vars.outputs.release-version }}
+ release: ${{ steps.vars.outputs.release }}
+ build-dir: ${{ steps.vars.outputs.build-dir }}
+ rc-flags: ${{ steps.vars.outputs.rc-flags }}
+ ref: ${{ steps.vars.outputs.ref }}
+ upload: ${{ steps.vars.outputs.upload }}
steps:
- name: Checkout LLVM
uses: actions/checkout@v4
-- name: Validate and parse tag
- id: validate-tag
+- name: Check Permissions
+ env:
+GITHUB_TOKEN: ${{ github.token }}
+ run: |
+./llvm/utils/release/./github-upload-release.py --token
"$GITHUB_TOKEN" --user ${{ github.actor }} check-permissions
+
+- name: Collect Variables
+ id: vars
# In order for the test-release.sh script to run correctly, the LLVM
# source needs to be at the following location relative to the build dir:
# | X.Y.Z-rcN | ./rcN/llvm-project
@@ -47,15 +61,12 @@ jobs:
# | X.Y.Z-rcN | -rc N -test-asserts
# | X.Y.Z | -final
run: |
-tag="${{ github.ref_name }}"
-trimmed=$(echo ${{ inputs.tag }} | xargs)
-[[ "$trimmed" != "" ]] && tag="$trimmed"
if [ -n "${{ inputs.upload }}" ]; then
upload="${{ inputs.upload }}"
else
- upload="true"
+ upload="false"
fi
-bash .github/workflows/set-release-binary-outputs.sh "${{ github.actor
}}" "$tag" "$upload"
+bash .github/workflows/set-release-binary-outputs.sh "${{
inputs.release-version }}" "$upload"
# Try to get around the 6 hour timeout by first running a job to fill
# the build cache.
diff --git a/.github/workflows/release-documentation.yml
b/.github/workflows/release-documentation.yml
new file mode 100644
index 00..832570ed6fe93f
--- /dev/null
+++ b/.github/workflows/release-documentation.yml
@@ -0,0 +1,84 @@
+name: Release Documentation
+
+permissions:
+ contents: read
+
+on:
+ workflow_dispatch:
+inputs:
+ release-version:
+description: 'Release Version'
+required: true
+type: string
+ upload:
+description: 'Upload documentation'
+required: false
+type: boolean
+
+ workflow_call:
+
[clang] [llvm] [clang-tools-extra] workflows: Refactor release-tasks.yml (PR #69523)
@@ -26,21 +35,26 @@ jobs:
prepare:
name: Prepare to build binaries
runs-on: ubuntu-22.04
-if: github.repository == 'llvm/llvm-project'
outputs:
- release-version: ${{ steps.validate-tag.outputs.release-version }}
- flags: ${{ steps.validate-tag.outputs.flags }}
- build-dir: ${{ steps.validate-tag.outputs.build-dir }}
- rc-flags: ${{ steps.validate-tag.outputs.rc-flags }}
- ref: ${{ steps.validate-tag.outputs.ref }}
- upload: ${{ steps.validate-tag.outputs.upload }}
+ release-version: ${{ steps.vars.outputs.release-version }}
+ flags: ${{ steps.vars.outputs.flags }}
+ build-dir: ${{ steps.vars.outputs.build-dir }}
+ rc-flags: ${{ steps.vars.outputs.rc-flags }}
+ ref: ${{ steps.vars.outputs.ref }}
+ upload: ${{ steps.vars.outputs.upload }}
steps:
- name: Checkout LLVM
uses: actions/checkout@v4
-- name: Validate and parse tag
- id: validate-tag
+- name: Check Permissions
+ env:
+GITHUB_TOKEN: ${{ github.token }}
+ run: |
+./llvm/utils/release/./github-upload-release.py --token
"$GITHUB_TOKEN" --user ${{ github.actor }} check-permissions
tstellar wrote:
I want to make sure that only the release managers are allowed to run this job
manually, because we have a limited budget for using the bigger runners and I
don't want to use it up.
https://github.com/llvm/llvm-project/pull/69523
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang-tools-extra] [llvm] [clang] workflows: Refactor release-tasks.yml (PR #69523)
tstellar wrote: Ping. https://github.com/llvm/llvm-project/pull/69523 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang-tools-extra] [clang] [llvm] workflows: Refactor release-tasks.yml (PR #69523)
https://github.com/tstellar updated
https://github.com/llvm/llvm-project/pull/69523
>From 6a7f298f403e0e454644f3d945242120f8b2b321 Mon Sep 17 00:00:00 2001
From: Tom Stellard
Date: Wed, 18 Oct 2023 04:56:28 -0700
Subject: [PATCH 1/5] workflows: Refactor release-tasks.yml
* Split out the lit release job and the documentation build jobs into their
own workflow files. This makes it possible to manually run these jobs
via workflow_dispatch.
* Improve tag/user validation and ensure it gets run for each release
task.
---
.github/workflows/release-binaries.yml| 51 ---
.github/workflows/release-documentation.yml | 84 +++
.github/workflows/release-doxygen.yml | 62
.github/workflows/release-lit.yml | 74 +
.github/workflows/release-tasks.yml | 140 ++
.../workflows/set-release-binary-outputs.sh | 18 +--
llvm/utils/release/github-upload-release.py | 22 ++-
7 files changed, 321 insertions(+), 130 deletions(-)
create mode 100644 .github/workflows/release-documentation.yml
create mode 100644 .github/workflows/release-doxygen.yml
create mode 100644 .github/workflows/release-lit.yml
diff --git a/.github/workflows/release-binaries.yml
b/.github/workflows/release-binaries.yml
index 75d4f419ab1fdc..d8b732413d2bf6 100644
--- a/.github/workflows/release-binaries.yml
+++ b/.github/workflows/release-binaries.yml
@@ -1,20 +1,29 @@
name: Release Binaries
on:
- push:
-tags:
- - 'llvmorg-*'
workflow_dispatch:
inputs:
+ release-version:
+description: 'Release Version'
+required: true
+type: string
upload:
description: 'Upload binaries to the release page'
required: true
-default: true
+default: false
type: boolean
- tag:
-description: 'Tag to build'
+
+ workflow_call:
+inputs:
+ release-version:
+description: 'Release Version'
required: true
type: string
+ upload:
+description: 'Upload binaries to the release page'
+required: true
+default: false
+type: boolean
permissions:
contents: read # Default everything to read-only
@@ -23,21 +32,26 @@ jobs:
prepare:
name: Prepare to build binaries
runs-on: ubuntu-22.04
-if: github.repository == 'llvm/llvm-project'
outputs:
- release-version: ${{ steps.validate-tag.outputs.release-version }}
- release: ${{ steps.validate-tag.outputs.release }}
- build-dir: ${{ steps.validate-tag.outputs.build-dir }}
- rc-flags: ${{ steps.validate-tag.outputs.rc-flags }}
- ref: ${{ steps.validate-tag.outputs.ref }}
- upload: ${{ steps.validate-tag.outputs.upload }}
+ release-version: ${{ steps.vars.outputs.release-version }}
+ release: ${{ steps.vars.outputs.release }}
+ build-dir: ${{ steps.vars.outputs.build-dir }}
+ rc-flags: ${{ steps.vars.outputs.rc-flags }}
+ ref: ${{ steps.vars.outputs.ref }}
+ upload: ${{ steps.vars.outputs.upload }}
steps:
- name: Checkout LLVM
uses: actions/checkout@v4
-- name: Validate and parse tag
- id: validate-tag
+- name: Check Permissions
+ env:
+GITHUB_TOKEN: ${{ github.token }}
+ run: |
+./llvm/utils/release/./github-upload-release.py --token
"$GITHUB_TOKEN" --user ${{ github.actor }} check-permissions
+
+- name: Collect Variables
+ id: vars
# In order for the test-release.sh script to run correctly, the LLVM
# source needs to be at the following location relative to the build dir:
# | X.Y.Z-rcN | ./rcN/llvm-project
@@ -47,15 +61,12 @@ jobs:
# | X.Y.Z-rcN | -rc N -test-asserts
# | X.Y.Z | -final
run: |
-tag="${{ github.ref_name }}"
-trimmed=$(echo ${{ inputs.tag }} | xargs)
-[[ "$trimmed" != "" ]] && tag="$trimmed"
if [ -n "${{ inputs.upload }}" ]; then
upload="${{ inputs.upload }}"
else
- upload="true"
+ upload="false"
fi
-bash .github/workflows/set-release-binary-outputs.sh "${{ github.actor
}}" "$tag" "$upload"
+bash .github/workflows/set-release-binary-outputs.sh "${{
inputs.release-version }}" "$upload"
# Try to get around the 6 hour timeout by first running a job to fill
# the build cache.
diff --git a/.github/workflows/release-documentation.yml
b/.github/workflows/release-documentation.yml
new file mode 100644
index 00..832570ed6fe93f
--- /dev/null
+++ b/.github/workflows/release-documentation.yml
@@ -0,0 +1,84 @@
+name: Release Documentation
+
+permissions:
+ contents: read
+
+on:
+ workflow_dispatch:
+inputs:
+ release-version:
+description: 'Release Version'
+required: true
+type: string
+ upload:
+description: 'Upload documentation'
+required: false
+type: boolean
+
+ workflow_call:
+
[clang-tools-extra] [clang] [llvm] workflows: Refactor release-tasks.yml (PR #69523)
https://github.com/tstellar updated
https://github.com/llvm/llvm-project/pull/69523
>From 6a7f298f403e0e454644f3d945242120f8b2b321 Mon Sep 17 00:00:00 2001
From: Tom Stellard
Date: Wed, 18 Oct 2023 04:56:28 -0700
Subject: [PATCH 1/4] workflows: Refactor release-tasks.yml
* Split out the lit release job and the documentation build jobs into their
own workflow files. This makes it possible to manually run these jobs
via workflow_dispatch.
* Improve tag/user validation and ensure it gets run for each release
task.
---
.github/workflows/release-binaries.yml| 51 ---
.github/workflows/release-documentation.yml | 84 +++
.github/workflows/release-doxygen.yml | 62
.github/workflows/release-lit.yml | 74 +
.github/workflows/release-tasks.yml | 140 ++
.../workflows/set-release-binary-outputs.sh | 18 +--
llvm/utils/release/github-upload-release.py | 22 ++-
7 files changed, 321 insertions(+), 130 deletions(-)
create mode 100644 .github/workflows/release-documentation.yml
create mode 100644 .github/workflows/release-doxygen.yml
create mode 100644 .github/workflows/release-lit.yml
diff --git a/.github/workflows/release-binaries.yml
b/.github/workflows/release-binaries.yml
index 75d4f419ab1fdc..d8b732413d2bf6 100644
--- a/.github/workflows/release-binaries.yml
+++ b/.github/workflows/release-binaries.yml
@@ -1,20 +1,29 @@
name: Release Binaries
on:
- push:
-tags:
- - 'llvmorg-*'
workflow_dispatch:
inputs:
+ release-version:
+description: 'Release Version'
+required: true
+type: string
upload:
description: 'Upload binaries to the release page'
required: true
-default: true
+default: false
type: boolean
- tag:
-description: 'Tag to build'
+
+ workflow_call:
+inputs:
+ release-version:
+description: 'Release Version'
required: true
type: string
+ upload:
+description: 'Upload binaries to the release page'
+required: true
+default: false
+type: boolean
permissions:
contents: read # Default everything to read-only
@@ -23,21 +32,26 @@ jobs:
prepare:
name: Prepare to build binaries
runs-on: ubuntu-22.04
-if: github.repository == 'llvm/llvm-project'
outputs:
- release-version: ${{ steps.validate-tag.outputs.release-version }}
- release: ${{ steps.validate-tag.outputs.release }}
- build-dir: ${{ steps.validate-tag.outputs.build-dir }}
- rc-flags: ${{ steps.validate-tag.outputs.rc-flags }}
- ref: ${{ steps.validate-tag.outputs.ref }}
- upload: ${{ steps.validate-tag.outputs.upload }}
+ release-version: ${{ steps.vars.outputs.release-version }}
+ release: ${{ steps.vars.outputs.release }}
+ build-dir: ${{ steps.vars.outputs.build-dir }}
+ rc-flags: ${{ steps.vars.outputs.rc-flags }}
+ ref: ${{ steps.vars.outputs.ref }}
+ upload: ${{ steps.vars.outputs.upload }}
steps:
- name: Checkout LLVM
uses: actions/checkout@v4
-- name: Validate and parse tag
- id: validate-tag
+- name: Check Permissions
+ env:
+GITHUB_TOKEN: ${{ github.token }}
+ run: |
+./llvm/utils/release/./github-upload-release.py --token
"$GITHUB_TOKEN" --user ${{ github.actor }} check-permissions
+
+- name: Collect Variables
+ id: vars
# In order for the test-release.sh script to run correctly, the LLVM
# source needs to be at the following location relative to the build dir:
# | X.Y.Z-rcN | ./rcN/llvm-project
@@ -47,15 +61,12 @@ jobs:
# | X.Y.Z-rcN | -rc N -test-asserts
# | X.Y.Z | -final
run: |
-tag="${{ github.ref_name }}"
-trimmed=$(echo ${{ inputs.tag }} | xargs)
-[[ "$trimmed" != "" ]] && tag="$trimmed"
if [ -n "${{ inputs.upload }}" ]; then
upload="${{ inputs.upload }}"
else
- upload="true"
+ upload="false"
fi
-bash .github/workflows/set-release-binary-outputs.sh "${{ github.actor
}}" "$tag" "$upload"
+bash .github/workflows/set-release-binary-outputs.sh "${{
inputs.release-version }}" "$upload"
# Try to get around the 6 hour timeout by first running a job to fill
# the build cache.
diff --git a/.github/workflows/release-documentation.yml
b/.github/workflows/release-documentation.yml
new file mode 100644
index 00..832570ed6fe93f
--- /dev/null
+++ b/.github/workflows/release-documentation.yml
@@ -0,0 +1,84 @@
+name: Release Documentation
+
+permissions:
+ contents: read
+
+on:
+ workflow_dispatch:
+inputs:
+ release-version:
+description: 'Release Version'
+required: true
+type: string
+ upload:
+description: 'Upload documentation'
+required: false
+type: boolean
+
+ workflow_call:
+
[llvm] [clang-tools-extra] [clang] Add OpenSSF Best Practice Badge (PR #77398)
https://github.com/tstellar closed https://github.com/llvm/llvm-project/pull/77398 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[llvm] [clang-tools-extra] [clang] Add OpenSSF Best Practice Badge (PR #77398)
https://github.com/tstellar updated https://github.com/llvm/llvm-project/pull/77398 >From 71574d1f8b37747b2b7176fffee8483a53fee4be Mon Sep 17 00:00:00 2001 From: Tom Stellard Date: Mon, 8 Jan 2024 16:39:00 -0800 Subject: [PATCH] Add OpenSSF Best Practice Badge --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index 4ae7eaf9b083a5..186cd310bfbb6b 100644 --- a/README.md +++ b/README.md @@ -1,6 +1,7 @@ # The LLVM Compiler Infrastructure [](https://securityscorecards.dev/viewer/?uri=github.com/llvm/llvm-project) +[](https://www.bestpractices.dev/projects/8273) Welcome to the LLVM project! ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [CMake][PGO] Build Sema.cpp to generate profdata for PGO builds (PR #77347)
@@ -26,9 +30,23 @@ if(LLVM_BUILD_INSTRUMENTED)
message(STATUS "To enable merging PGO data LLVM_PROFDATA has to point to
llvm-profdata")
else()
add_custom_target(generate-profdata
- COMMAND "${Python3_EXECUTABLE}"
${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py merge ${LLVM_PROFDATA}
${CMAKE_CURRENT_BINARY_DIR}/clang.profdata ${CMAKE_CURRENT_BINARY_DIR}
+ COMMAND "${Python3_EXECUTABLE}"
${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py merge ${LLVM_PROFDATA}
${CMAKE_CURRENT_BINARY_DIR}/clang.profdata ${CMAKE_CURRENT_BINARY_DIR}
${CMAKE_BINARY_DIR}/profiles/
COMMENT "Merging profdata"
DEPENDS generate-profraw)
+if (CLANG_PGO_TRAINING_DATA_SOURCE_DIR)
+ llvm_ExternalProject_Add(generate-profraw-external
${CLANG_PGO_TRAINING_DATA_SOURCE_DIR}
+ USE_TOOLCHAIN EXLUDE_FROM_ALL NO_INSTALL DEPENDS
generate-profraw)
+ add_dependencies(generate-profdata generate-profraw-external)
+else()
+ # Default to compiling a file from clang. This also builds all the
+ # dependencies needed to build this file, like TableGen.
+ set(generate_profraw_clang_sema
tools/clang/lib/Sema/CMakeFiles/obj.clangSema.dir/Sema.cpp.o)
+ llvm_ExternalProject_Add(generate-profraw-clang
${CMAKE_CURRENT_SOURCE_DIR}/../../../llvm
+ USE_TOOLCHAIN EXLUDE_FROM_ALL NO_INSTALL DEPENDS generate-profraw
+ EXTRA_TARGETS generate_profraw_clang_sema
tstellar wrote:
> If you're not concerned about the efficacy of the PGO build, I'm not sure why
> the existing single hello_world is a bad default. It isn't great but it is
> stable and something. If you want something that gives better performance
> then you must care about the efficacy, and I think you need to be somewhat
> concerned about the stability of those results, otherwise what's the point?
I'm concerned about the efficacy if it is 0%, but not really concerned if it
bounces around between say 10 and 25 % based on updates to the file we are
using to train.
I tested with the existing default (hello_world) and I didn't see any
performance improvements from that. We also did some manual builds (not using
the 2-stage PGO cache) and could not get any performance gains for using a
hello world source. How certain are we that hello_world is enough to get
performance improvements from PGO? Has anyone tested this recently? I will
re-run my tests just to double check.
https://github.com/llvm/llvm-project/pull/77347
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[llvm] [clang] [CMake][PGO] Build Sema.cpp to generate profdata for PGO builds (PR #77347)
@@ -26,9 +30,23 @@ if(LLVM_BUILD_INSTRUMENTED)
message(STATUS "To enable merging PGO data LLVM_PROFDATA has to point to
llvm-profdata")
else()
add_custom_target(generate-profdata
- COMMAND "${Python3_EXECUTABLE}"
${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py merge ${LLVM_PROFDATA}
${CMAKE_CURRENT_BINARY_DIR}/clang.profdata ${CMAKE_CURRENT_BINARY_DIR}
+ COMMAND "${Python3_EXECUTABLE}"
${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py merge ${LLVM_PROFDATA}
${CMAKE_CURRENT_BINARY_DIR}/clang.profdata ${CMAKE_CURRENT_BINARY_DIR}
${CMAKE_BINARY_DIR}/profiles/
COMMENT "Merging profdata"
DEPENDS generate-profraw)
+if (CLANG_PGO_TRAINING_DATA_SOURCE_DIR)
+ llvm_ExternalProject_Add(generate-profraw-external
${CLANG_PGO_TRAINING_DATA_SOURCE_DIR}
+ USE_TOOLCHAIN EXLUDE_FROM_ALL NO_INSTALL DEPENDS
generate-profraw)
+ add_dependencies(generate-profdata generate-profraw-external)
+else()
+ # Default to compiling a file from clang. This also builds all the
+ # dependencies needed to build this file, like TableGen.
+ set(generate_profraw_clang_sema
tools/clang/lib/Sema/CMakeFiles/obj.clangSema.dir/Sema.cpp.o)
+ llvm_ExternalProject_Add(generate-profraw-clang
${CMAKE_CURRENT_SOURCE_DIR}/../../../llvm
+ USE_TOOLCHAIN EXLUDE_FROM_ALL NO_INSTALL DEPENDS generate-profraw
+ EXTRA_TARGETS generate_profraw_clang_sema
tstellar wrote:
> This is going to be really fragile. The paths of object file outputs are an
> implementation detail of CMake that has changed in the past and could change
> in the future, also I think only the makefile and ninja generator actually
> export those as buildable targets.
>
What about using the library target `clangSema` instead of the individual file?
> Beyond that I also have a philosophical problem with the approach of using
> living clang sources as training data. I think this can result in
> unexplainable or difficult to diagnose differences in the efficacy of PGO
> because as you change the compiler you're also innately changing the training
> data. A potential better solution would be to have a preprocessed Sema.cpp
> from a recent LLVM release that we check in as a stable copy. This would be
> similar to how the GCC compile-time benchmark works.
The first thing I tried to do was add a preprocessed version of
CommentSema.cpp, but the file was 10MB, and I thought that might be too big.
Sema.cpp preprocessed is 5MB, which is smaller but still pretty big. I would
be OK with this approach if we think it's OK to add a big file like this to the
repo.
I'm also not concerned about efficacy of PGO, because building Sema.cpp is just
the default. I really want there to be a good default experience for users, so
that they can use the PGO cache files and things will 'just work'. This patch
also adds a configuration option for advanced users that need something more
consistent.
https://github.com/llvm/llvm-project/pull/77347
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[llvm] [clang] [CMake][PGO] Build Sema.cpp to generate profdata for PGO builds (PR #77347)
https://github.com/tstellar updated
https://github.com/llvm/llvm-project/pull/77347
>From 127e2ae83f33843cfb9c5cca314afa2fc9844239 Mon Sep 17 00:00:00 2001
From: Tom Stellard
Date: Sat, 6 Jan 2024 07:46:01 +
Subject: [PATCH 1/6] [CMake][PGO] Use check-clang target to generate profdata
for PGO builds
When doing a multi-stage PGO build of clang, run the check-clang and
check-llvm targets using the instrumented clang and use that profile
data for building the final stage2 clang. This is what is recommended
by our official documentation:
https://llvm.org/docs/HowToBuildWithPGO.html#building-clang-with-pgo
I benchmarked this change by compiling the SemaChecking.cpp file from
clang. Using check-clang/check-llvm to generate the profile data gives a 25%
speedup
in the PGO+LTO stage2 clang when compared to the stage1 clang (no-LTO).
Prior to this change, I was only seeing ~5% speedup when comparing the
stage2 and stage1 builds.
---
clang/utils/perf-training/CMakeLists.txt | 6 +++---
clang/utils/perf-training/perf-helper.py | 16 +---
2 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/clang/utils/perf-training/CMakeLists.txt
b/clang/utils/perf-training/CMakeLists.txt
index c6d51863fb1b5c..95ff8115aa538b 100644
--- a/clang/utils/perf-training/CMakeLists.txt
+++ b/clang/utils/perf-training/CMakeLists.txt
@@ -15,7 +15,7 @@ if(LLVM_BUILD_INSTRUMENTED)
)
add_custom_target(clear-profraw
-COMMAND "${Python3_EXECUTABLE}" ${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py
clean ${CMAKE_CURRENT_BINARY_DIR} profraw
+COMMAND "${Python3_EXECUTABLE}" ${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py
clean ${CMAKE_CURRENT_BINARY_DIR} ${CMAKE_BINARY_DIR}/profiles/ profraw
COMMENT "Clearing old profraw data")
if(NOT LLVM_PROFDATA)
@@ -26,9 +26,9 @@ if(LLVM_BUILD_INSTRUMENTED)
message(STATUS "To enable merging PGO data LLVM_PROFDATA has to point to
llvm-profdata")
else()
add_custom_target(generate-profdata
- COMMAND "${Python3_EXECUTABLE}"
${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py merge ${LLVM_PROFDATA}
${CMAKE_CURRENT_BINARY_DIR}/clang.profdata ${CMAKE_CURRENT_BINARY_DIR}
+ COMMAND "${Python3_EXECUTABLE}"
${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py merge ${LLVM_PROFDATA}
${CMAKE_CURRENT_BINARY_DIR}/clang.profdata ${CMAKE_CURRENT_BINARY_DIR}
${CMAKE_BINARY_DIR}/profiles/
COMMENT "Merging profdata"
- DEPENDS generate-profraw)
+ DEPENDS generate-profraw check-clang check-llvm)
endif()
endif()
diff --git a/clang/utils/perf-training/perf-helper.py
b/clang/utils/perf-training/perf-helper.py
index 99d6ab6ef0..bd8f74c9c2e129 100644
--- a/clang/utils/perf-training/perf-helper.py
+++ b/clang/utils/perf-training/perf-helper.py
@@ -30,26 +30,28 @@ def findFilesWithExtension(path, extension):
def clean(args):
-if len(args) != 2:
+if len(args) < 2:
print(
-"Usage: %s clean \n" % __file__
+"Usage: %s clean \n" % __file__
+ "\tRemoves all files with extension from ."
)
return 1
-for filename in findFilesWithExtension(args[0], args[1]):
-os.remove(filename)
+for path in args[1:-1]:
+ for filename in findFilesWithExtension(path, args[-1]):
+ os.remove(filename)
return 0
def merge(args):
-if len(args) != 3:
+if len(args) < 3:
print(
-"Usage: %s merge \n" % __file__
+"Usage: %s merge \n" % __file__
+ "\tMerges all profraw files from path into output."
)
return 1
cmd = [args[0], "merge", "-o", args[1]]
-cmd.extend(findFilesWithExtension(args[2], "profraw"))
+for i in range(2, len(args)):
+ cmd.extend(findFilesWithExtension(args[i], "profraw"))
subprocess.check_call(cmd)
return 0
>From 4f7734584af3aa9a18bde17349ceccbef3658c53 Mon Sep 17 00:00:00 2001
From: Tom Stellard
Date: Mon, 8 Jan 2024 18:07:31 +
Subject: [PATCH 2/6] Fix python formatting
---
clang/utils/perf-training/perf-helper.py | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/clang/utils/perf-training/perf-helper.py
b/clang/utils/perf-training/perf-helper.py
index bd8f74c9c2e129..844aa274f049aa 100644
--- a/clang/utils/perf-training/perf-helper.py
+++ b/clang/utils/perf-training/perf-helper.py
@@ -37,8 +37,8 @@ def clean(args):
)
return 1
for path in args[1:-1]:
- for filename in findFilesWithExtension(path, args[-1]):
- os.remove(filename)
+for filename in findFilesWithExtension(path, args[-1]):
+os.remove(filename)
return 0
@@ -51,7 +51,7 @@ def merge(args):
return 1
cmd = [args[0], "merge", "-o", args[1]]
for i in range(2, len(args)):
- cmd.extend(findFilesWithExtension(args[i], "profraw"))
+cmd.extend(findFilesWithExtension(args[i], "profraw"))
subprocess.check_call(cmd)
return 0
>From
[clang] [CMake][Release] Add option for enabling LTO to cache file (PR #77035)
https://github.com/tstellar closed https://github.com/llvm/llvm-project/pull/77035 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[llvm] [clang] [CMake][PGO] Build Sema.cpp to generate profdata for PGO builds (PR #77347)
https://github.com/tstellar updated
https://github.com/llvm/llvm-project/pull/77347
>From 127e2ae83f33843cfb9c5cca314afa2fc9844239 Mon Sep 17 00:00:00 2001
From: Tom Stellard
Date: Sat, 6 Jan 2024 07:46:01 +
Subject: [PATCH 1/5] [CMake][PGO] Use check-clang target to generate profdata
for PGO builds
When doing a multi-stage PGO build of clang, run the check-clang and
check-llvm targets using the instrumented clang and use that profile
data for building the final stage2 clang. This is what is recommended
by our official documentation:
https://llvm.org/docs/HowToBuildWithPGO.html#building-clang-with-pgo
I benchmarked this change by compiling the SemaChecking.cpp file from
clang. Using check-clang/check-llvm to generate the profile data gives a 25%
speedup
in the PGO+LTO stage2 clang when compared to the stage1 clang (no-LTO).
Prior to this change, I was only seeing ~5% speedup when comparing the
stage2 and stage1 builds.
---
clang/utils/perf-training/CMakeLists.txt | 6 +++---
clang/utils/perf-training/perf-helper.py | 16 +---
2 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/clang/utils/perf-training/CMakeLists.txt
b/clang/utils/perf-training/CMakeLists.txt
index c6d51863fb1b5c..95ff8115aa538b 100644
--- a/clang/utils/perf-training/CMakeLists.txt
+++ b/clang/utils/perf-training/CMakeLists.txt
@@ -15,7 +15,7 @@ if(LLVM_BUILD_INSTRUMENTED)
)
add_custom_target(clear-profraw
-COMMAND "${Python3_EXECUTABLE}" ${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py
clean ${CMAKE_CURRENT_BINARY_DIR} profraw
+COMMAND "${Python3_EXECUTABLE}" ${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py
clean ${CMAKE_CURRENT_BINARY_DIR} ${CMAKE_BINARY_DIR}/profiles/ profraw
COMMENT "Clearing old profraw data")
if(NOT LLVM_PROFDATA)
@@ -26,9 +26,9 @@ if(LLVM_BUILD_INSTRUMENTED)
message(STATUS "To enable merging PGO data LLVM_PROFDATA has to point to
llvm-profdata")
else()
add_custom_target(generate-profdata
- COMMAND "${Python3_EXECUTABLE}"
${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py merge ${LLVM_PROFDATA}
${CMAKE_CURRENT_BINARY_DIR}/clang.profdata ${CMAKE_CURRENT_BINARY_DIR}
+ COMMAND "${Python3_EXECUTABLE}"
${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py merge ${LLVM_PROFDATA}
${CMAKE_CURRENT_BINARY_DIR}/clang.profdata ${CMAKE_CURRENT_BINARY_DIR}
${CMAKE_BINARY_DIR}/profiles/
COMMENT "Merging profdata"
- DEPENDS generate-profraw)
+ DEPENDS generate-profraw check-clang check-llvm)
endif()
endif()
diff --git a/clang/utils/perf-training/perf-helper.py
b/clang/utils/perf-training/perf-helper.py
index 99d6ab6ef0..bd8f74c9c2e129 100644
--- a/clang/utils/perf-training/perf-helper.py
+++ b/clang/utils/perf-training/perf-helper.py
@@ -30,26 +30,28 @@ def findFilesWithExtension(path, extension):
def clean(args):
-if len(args) != 2:
+if len(args) < 2:
print(
-"Usage: %s clean \n" % __file__
+"Usage: %s clean \n" % __file__
+ "\tRemoves all files with extension from ."
)
return 1
-for filename in findFilesWithExtension(args[0], args[1]):
-os.remove(filename)
+for path in args[1:-1]:
+ for filename in findFilesWithExtension(path, args[-1]):
+ os.remove(filename)
return 0
def merge(args):
-if len(args) != 3:
+if len(args) < 3:
print(
-"Usage: %s merge \n" % __file__
+"Usage: %s merge \n" % __file__
+ "\tMerges all profraw files from path into output."
)
return 1
cmd = [args[0], "merge", "-o", args[1]]
-cmd.extend(findFilesWithExtension(args[2], "profraw"))
+for i in range(2, len(args)):
+ cmd.extend(findFilesWithExtension(args[i], "profraw"))
subprocess.check_call(cmd)
return 0
>From 4f7734584af3aa9a18bde17349ceccbef3658c53 Mon Sep 17 00:00:00 2001
From: Tom Stellard
Date: Mon, 8 Jan 2024 18:07:31 +
Subject: [PATCH 2/5] Fix python formatting
---
clang/utils/perf-training/perf-helper.py | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/clang/utils/perf-training/perf-helper.py
b/clang/utils/perf-training/perf-helper.py
index bd8f74c9c2e129..844aa274f049aa 100644
--- a/clang/utils/perf-training/perf-helper.py
+++ b/clang/utils/perf-training/perf-helper.py
@@ -37,8 +37,8 @@ def clean(args):
)
return 1
for path in args[1:-1]:
- for filename in findFilesWithExtension(path, args[-1]):
- os.remove(filename)
+for filename in findFilesWithExtension(path, args[-1]):
+os.remove(filename)
return 0
@@ -51,7 +51,7 @@ def merge(args):
return 1
cmd = [args[0], "merge", "-o", args[1]]
for i in range(2, len(args)):
- cmd.extend(findFilesWithExtension(args[i], "profraw"))
+cmd.extend(findFilesWithExtension(args[i], "profraw"))
subprocess.check_call(cmd)
return 0
>From
[llvm] [clang] [CMake][PGO] Build Sema.cpp to generate profdata for PGO builds (PR #77347)
tstellar wrote: cc @zmodem Since I borrowed your idea from #71067. https://github.com/llvm/llvm-project/pull/77347 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [CMake][PGO] Build Sema.cpp to generate profdata for PGO builds (PR #77347)
tstellar wrote: I was able to figure out how to generate profile data by compiling Sema.cpp from the clang source tree, so I switched that to the default and added an option so that users can override this with an external CMake project, like the LLVM Test Suite. https://github.com/llvm/llvm-project/pull/77347 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [CMake][PGO] Build Sema.cpp to generate profdata for PGO builds (PR #77347)
https://github.com/tstellar edited https://github.com/llvm/llvm-project/pull/77347 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[llvm] [clang] [CMake][PGO] Build Sema.cpp to generate profdata for PGO builds (PR #77347)
https://github.com/tstellar edited https://github.com/llvm/llvm-project/pull/77347 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[llvm] [clang] [CMake][PGO] Use check targets to generate profdata for PGO builds (PR #77347)
https://github.com/tstellar updated
https://github.com/llvm/llvm-project/pull/77347
>From 127e2ae83f33843cfb9c5cca314afa2fc9844239 Mon Sep 17 00:00:00 2001
From: Tom Stellard
Date: Sat, 6 Jan 2024 07:46:01 +
Subject: [PATCH 1/4] [CMake][PGO] Use check-clang target to generate profdata
for PGO builds
When doing a multi-stage PGO build of clang, run the check-clang and
check-llvm targets using the instrumented clang and use that profile
data for building the final stage2 clang. This is what is recommended
by our official documentation:
https://llvm.org/docs/HowToBuildWithPGO.html#building-clang-with-pgo
I benchmarked this change by compiling the SemaChecking.cpp file from
clang. Using check-clang/check-llvm to generate the profile data gives a 25%
speedup
in the PGO+LTO stage2 clang when compared to the stage1 clang (no-LTO).
Prior to this change, I was only seeing ~5% speedup when comparing the
stage2 and stage1 builds.
---
clang/utils/perf-training/CMakeLists.txt | 6 +++---
clang/utils/perf-training/perf-helper.py | 16 +---
2 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/clang/utils/perf-training/CMakeLists.txt
b/clang/utils/perf-training/CMakeLists.txt
index c6d51863fb1b5c..95ff8115aa538b 100644
--- a/clang/utils/perf-training/CMakeLists.txt
+++ b/clang/utils/perf-training/CMakeLists.txt
@@ -15,7 +15,7 @@ if(LLVM_BUILD_INSTRUMENTED)
)
add_custom_target(clear-profraw
-COMMAND "${Python3_EXECUTABLE}" ${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py
clean ${CMAKE_CURRENT_BINARY_DIR} profraw
+COMMAND "${Python3_EXECUTABLE}" ${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py
clean ${CMAKE_CURRENT_BINARY_DIR} ${CMAKE_BINARY_DIR}/profiles/ profraw
COMMENT "Clearing old profraw data")
if(NOT LLVM_PROFDATA)
@@ -26,9 +26,9 @@ if(LLVM_BUILD_INSTRUMENTED)
message(STATUS "To enable merging PGO data LLVM_PROFDATA has to point to
llvm-profdata")
else()
add_custom_target(generate-profdata
- COMMAND "${Python3_EXECUTABLE}"
${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py merge ${LLVM_PROFDATA}
${CMAKE_CURRENT_BINARY_DIR}/clang.profdata ${CMAKE_CURRENT_BINARY_DIR}
+ COMMAND "${Python3_EXECUTABLE}"
${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py merge ${LLVM_PROFDATA}
${CMAKE_CURRENT_BINARY_DIR}/clang.profdata ${CMAKE_CURRENT_BINARY_DIR}
${CMAKE_BINARY_DIR}/profiles/
COMMENT "Merging profdata"
- DEPENDS generate-profraw)
+ DEPENDS generate-profraw check-clang check-llvm)
endif()
endif()
diff --git a/clang/utils/perf-training/perf-helper.py
b/clang/utils/perf-training/perf-helper.py
index 99d6ab6ef0..bd8f74c9c2e129 100644
--- a/clang/utils/perf-training/perf-helper.py
+++ b/clang/utils/perf-training/perf-helper.py
@@ -30,26 +30,28 @@ def findFilesWithExtension(path, extension):
def clean(args):
-if len(args) != 2:
+if len(args) < 2:
print(
-"Usage: %s clean \n" % __file__
+"Usage: %s clean \n" % __file__
+ "\tRemoves all files with extension from ."
)
return 1
-for filename in findFilesWithExtension(args[0], args[1]):
-os.remove(filename)
+for path in args[1:-1]:
+ for filename in findFilesWithExtension(path, args[-1]):
+ os.remove(filename)
return 0
def merge(args):
-if len(args) != 3:
+if len(args) < 3:
print(
-"Usage: %s merge \n" % __file__
+"Usage: %s merge \n" % __file__
+ "\tMerges all profraw files from path into output."
)
return 1
cmd = [args[0], "merge", "-o", args[1]]
-cmd.extend(findFilesWithExtension(args[2], "profraw"))
+for i in range(2, len(args)):
+ cmd.extend(findFilesWithExtension(args[i], "profraw"))
subprocess.check_call(cmd)
return 0
>From 4f7734584af3aa9a18bde17349ceccbef3658c53 Mon Sep 17 00:00:00 2001
From: Tom Stellard
Date: Mon, 8 Jan 2024 18:07:31 +
Subject: [PATCH 2/4] Fix python formatting
---
clang/utils/perf-training/perf-helper.py | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/clang/utils/perf-training/perf-helper.py
b/clang/utils/perf-training/perf-helper.py
index bd8f74c9c2e129..844aa274f049aa 100644
--- a/clang/utils/perf-training/perf-helper.py
+++ b/clang/utils/perf-training/perf-helper.py
@@ -37,8 +37,8 @@ def clean(args):
)
return 1
for path in args[1:-1]:
- for filename in findFilesWithExtension(path, args[-1]):
- os.remove(filename)
+for filename in findFilesWithExtension(path, args[-1]):
+os.remove(filename)
return 0
@@ -51,7 +51,7 @@ def merge(args):
return 1
cmd = [args[0], "merge", "-o", args[1]]
for i in range(2, len(args)):
- cmd.extend(findFilesWithExtension(args[i], "profraw"))
+cmd.extend(findFilesWithExtension(args[i], "profraw"))
subprocess.check_call(cmd)
return 0
>From
[clang] [CMake] Deprecate GCC_INSTALL_PREFIX (PR #77537)
https://github.com/tstellar approved this pull request. I'm in favor of removing this. It doesn't make a lot of sense now that we have better config file support. https://github.com/llvm/llvm-project/pull/77537 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Driver] Add the --gcc-triple option (PR #73214)
https://github.com/tstellar closed https://github.com/llvm/llvm-project/pull/73214 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CMake][PGO] Use check targets to generate profdata for PGO builds (PR #77347)
tstellar wrote: My goal right now is to make this simple and easy to use. I'm not opposed to making something configurable, but it would be nice to have a default that actually helped improve performance, so that a new user or a distribution maintainer could just use the cache file as is. What about if we tried to improve the existing in tree corpus (which only has hello-world). @petrhosek Is there anything in your corpus that you can contribute upstream? Any suggestions for what to put in there? Maybe a few of the bigger c++ files from in the tree? https://github.com/llvm/llvm-project/pull/77347 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CMake][PGO] Use check targets to generate profdata for PGO builds (PR #77347)
https://github.com/tstellar edited https://github.com/llvm/llvm-project/pull/77347 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CMake][PGO] Use check-clang target to generate profdata for PGO builds (PR #77347)
https://github.com/tstellar updated
https://github.com/llvm/llvm-project/pull/77347
>From 127e2ae83f33843cfb9c5cca314afa2fc9844239 Mon Sep 17 00:00:00 2001
From: Tom Stellard
Date: Sat, 6 Jan 2024 07:46:01 +
Subject: [PATCH 1/2] [CMake][PGO] Use check-clang target to generate profdata
for PGO builds
When doing a multi-stage PGO build of clang, run the check-clang and
check-llvm targets using the instrumented clang and use that profile
data for building the final stage2 clang. This is what is recommended
by our official documentation:
https://llvm.org/docs/HowToBuildWithPGO.html#building-clang-with-pgo
I benchmarked this change by compiling the SemaChecking.cpp file from
clang. Using check-clang/check-llvm to generate the profile data gives a 25%
speedup
in the PGO+LTO stage2 clang when compared to the stage1 clang (no-LTO).
Prior to this change, I was only seeing ~5% speedup when comparing the
stage2 and stage1 builds.
---
clang/utils/perf-training/CMakeLists.txt | 6 +++---
clang/utils/perf-training/perf-helper.py | 16 +---
2 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/clang/utils/perf-training/CMakeLists.txt
b/clang/utils/perf-training/CMakeLists.txt
index c6d51863fb1b5c..95ff8115aa538b 100644
--- a/clang/utils/perf-training/CMakeLists.txt
+++ b/clang/utils/perf-training/CMakeLists.txt
@@ -15,7 +15,7 @@ if(LLVM_BUILD_INSTRUMENTED)
)
add_custom_target(clear-profraw
-COMMAND "${Python3_EXECUTABLE}" ${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py
clean ${CMAKE_CURRENT_BINARY_DIR} profraw
+COMMAND "${Python3_EXECUTABLE}" ${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py
clean ${CMAKE_CURRENT_BINARY_DIR} ${CMAKE_BINARY_DIR}/profiles/ profraw
COMMENT "Clearing old profraw data")
if(NOT LLVM_PROFDATA)
@@ -26,9 +26,9 @@ if(LLVM_BUILD_INSTRUMENTED)
message(STATUS "To enable merging PGO data LLVM_PROFDATA has to point to
llvm-profdata")
else()
add_custom_target(generate-profdata
- COMMAND "${Python3_EXECUTABLE}"
${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py merge ${LLVM_PROFDATA}
${CMAKE_CURRENT_BINARY_DIR}/clang.profdata ${CMAKE_CURRENT_BINARY_DIR}
+ COMMAND "${Python3_EXECUTABLE}"
${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py merge ${LLVM_PROFDATA}
${CMAKE_CURRENT_BINARY_DIR}/clang.profdata ${CMAKE_CURRENT_BINARY_DIR}
${CMAKE_BINARY_DIR}/profiles/
COMMENT "Merging profdata"
- DEPENDS generate-profraw)
+ DEPENDS generate-profraw check-clang check-llvm)
endif()
endif()
diff --git a/clang/utils/perf-training/perf-helper.py
b/clang/utils/perf-training/perf-helper.py
index 99d6ab6ef0..bd8f74c9c2e129 100644
--- a/clang/utils/perf-training/perf-helper.py
+++ b/clang/utils/perf-training/perf-helper.py
@@ -30,26 +30,28 @@ def findFilesWithExtension(path, extension):
def clean(args):
-if len(args) != 2:
+if len(args) < 2:
print(
-"Usage: %s clean \n" % __file__
+"Usage: %s clean \n" % __file__
+ "\tRemoves all files with extension from ."
)
return 1
-for filename in findFilesWithExtension(args[0], args[1]):
-os.remove(filename)
+for path in args[1:-1]:
+ for filename in findFilesWithExtension(path, args[-1]):
+ os.remove(filename)
return 0
def merge(args):
-if len(args) != 3:
+if len(args) < 3:
print(
-"Usage: %s merge \n" % __file__
+"Usage: %s merge \n" % __file__
+ "\tMerges all profraw files from path into output."
)
return 1
cmd = [args[0], "merge", "-o", args[1]]
-cmd.extend(findFilesWithExtension(args[2], "profraw"))
+for i in range(2, len(args)):
+ cmd.extend(findFilesWithExtension(args[i], "profraw"))
subprocess.check_call(cmd)
return 0
>From 4f7734584af3aa9a18bde17349ceccbef3658c53 Mon Sep 17 00:00:00 2001
From: Tom Stellard
Date: Mon, 8 Jan 2024 18:07:31 +
Subject: [PATCH 2/2] Fix python formatting
---
clang/utils/perf-training/perf-helper.py | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/clang/utils/perf-training/perf-helper.py
b/clang/utils/perf-training/perf-helper.py
index bd8f74c9c2e129..844aa274f049aa 100644
--- a/clang/utils/perf-training/perf-helper.py
+++ b/clang/utils/perf-training/perf-helper.py
@@ -37,8 +37,8 @@ def clean(args):
)
return 1
for path in args[1:-1]:
- for filename in findFilesWithExtension(path, args[-1]):
- os.remove(filename)
+for filename in findFilesWithExtension(path, args[-1]):
+os.remove(filename)
return 0
@@ -51,7 +51,7 @@ def merge(args):
return 1
cmd = [args[0], "merge", "-o", args[1]]
for i in range(2, len(args)):
- cmd.extend(findFilesWithExtension(args[i], "profraw"))
+cmd.extend(findFilesWithExtension(args[i], "profraw"))
subprocess.check_call(cmd)
return 0
[clang] [CMake][PGO] Use check-clang target to generate profdata for PGO builds (PR #77347)
tstellar wrote: @kwk fyi https://github.com/llvm/llvm-project/pull/77347 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CMake][PGO] Use check-clang target to generate profdata for PGO builds (PR #77347)
https://github.com/tstellar created
https://github.com/llvm/llvm-project/pull/77347
When doing a multi-stage PGO build of clang, run the check-clang and check-llvm
targets using the instrumented clang and use that profile data for building the
final stage2 clang. This is what is recommended by our official documentation:
https://llvm.org/docs/HowToBuildWithPGO.html#building-clang-with-pgo
I benchmarked this change by compiling the SemaChecking.cpp file from clang.
Using check-clang/check-llvm to generate the profile data gives a 25% speedup
in the PGO+LTO stage2 clang when compared to the stage1 clang (no-LTO).
Prior to this change, I was only seeing ~5% speedup when comparing the stage2
and stage1 builds.
>From 127e2ae83f33843cfb9c5cca314afa2fc9844239 Mon Sep 17 00:00:00 2001
From: Tom Stellard
Date: Sat, 6 Jan 2024 07:46:01 +
Subject: [PATCH] [CMake][PGO] Use check-clang target to generate profdata for
PGO builds
When doing a multi-stage PGO build of clang, run the check-clang and
check-llvm targets using the instrumented clang and use that profile
data for building the final stage2 clang. This is what is recommended
by our official documentation:
https://llvm.org/docs/HowToBuildWithPGO.html#building-clang-with-pgo
I benchmarked this change by compiling the SemaChecking.cpp file from
clang. Using check-clang/check-llvm to generate the profile data gives a 25%
speedup
in the PGO+LTO stage2 clang when compared to the stage1 clang (no-LTO).
Prior to this change, I was only seeing ~5% speedup when comparing the
stage2 and stage1 builds.
---
clang/utils/perf-training/CMakeLists.txt | 6 +++---
clang/utils/perf-training/perf-helper.py | 16 +---
2 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/clang/utils/perf-training/CMakeLists.txt
b/clang/utils/perf-training/CMakeLists.txt
index c6d51863fb1b5c..95ff8115aa538b 100644
--- a/clang/utils/perf-training/CMakeLists.txt
+++ b/clang/utils/perf-training/CMakeLists.txt
@@ -15,7 +15,7 @@ if(LLVM_BUILD_INSTRUMENTED)
)
add_custom_target(clear-profraw
-COMMAND "${Python3_EXECUTABLE}" ${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py
clean ${CMAKE_CURRENT_BINARY_DIR} profraw
+COMMAND "${Python3_EXECUTABLE}" ${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py
clean ${CMAKE_CURRENT_BINARY_DIR} ${CMAKE_BINARY_DIR}/profiles/ profraw
COMMENT "Clearing old profraw data")
if(NOT LLVM_PROFDATA)
@@ -26,9 +26,9 @@ if(LLVM_BUILD_INSTRUMENTED)
message(STATUS "To enable merging PGO data LLVM_PROFDATA has to point to
llvm-profdata")
else()
add_custom_target(generate-profdata
- COMMAND "${Python3_EXECUTABLE}"
${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py merge ${LLVM_PROFDATA}
${CMAKE_CURRENT_BINARY_DIR}/clang.profdata ${CMAKE_CURRENT_BINARY_DIR}
+ COMMAND "${Python3_EXECUTABLE}"
${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py merge ${LLVM_PROFDATA}
${CMAKE_CURRENT_BINARY_DIR}/clang.profdata ${CMAKE_CURRENT_BINARY_DIR}
${CMAKE_BINARY_DIR}/profiles/
COMMENT "Merging profdata"
- DEPENDS generate-profraw)
+ DEPENDS generate-profraw check-clang check-llvm)
endif()
endif()
diff --git a/clang/utils/perf-training/perf-helper.py
b/clang/utils/perf-training/perf-helper.py
index 99d6ab6ef0..bd8f74c9c2e129 100644
--- a/clang/utils/perf-training/perf-helper.py
+++ b/clang/utils/perf-training/perf-helper.py
@@ -30,26 +30,28 @@ def findFilesWithExtension(path, extension):
def clean(args):
-if len(args) != 2:
+if len(args) < 2:
print(
-"Usage: %s clean \n" % __file__
+"Usage: %s clean \n" % __file__
+ "\tRemoves all files with extension from ."
)
return 1
-for filename in findFilesWithExtension(args[0], args[1]):
-os.remove(filename)
+for path in args[1:-1]:
+ for filename in findFilesWithExtension(path, args[-1]):
+ os.remove(filename)
return 0
def merge(args):
-if len(args) != 3:
+if len(args) < 3:
print(
-"Usage: %s merge \n" % __file__
+"Usage: %s merge \n" % __file__
+ "\tMerges all profraw files from path into output."
)
return 1
cmd = [args[0], "merge", "-o", args[1]]
-cmd.extend(findFilesWithExtension(args[2], "profraw"))
+for i in range(2, len(args)):
+ cmd.extend(findFilesWithExtension(args[i], "profraw"))
subprocess.check_call(cmd)
return 0
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [CMake][Release] Add option for enabling LTO to cache file (PR #77035)
https://github.com/tstellar updated
https://github.com/llvm/llvm-project/pull/77035
>From db643899042aea45da93c1738b523f139f307295 Mon Sep 17 00:00:00 2001
From: Tom Stellard
Date: Fri, 5 Jan 2024 00:58:58 +
Subject: [PATCH] [CMake][Release] Add option for enabling LTO to cache file
This option is LLVM_RELEASE_ENABLE_LTO and it's turned on by default.
---
clang/cmake/caches/Release.cmake | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/clang/cmake/caches/Release.cmake b/clang/cmake/caches/Release.cmake
index 3ea65ce26296c8..a7b9a8d0e29f88 100644
--- a/clang/cmake/caches/Release.cmake
+++ b/clang/cmake/caches/Release.cmake
@@ -2,6 +2,9 @@
# BOOTSTRAP_* options configure the second build.
# BOOTSTRAP_BOOTSTRAP_* options configure the third build.
+# General Options
+set(LLVM_RELEASE_ENABLE_LTO THIN CACHE STRING "")
+
set(CMAKE_BUILD_TYPE RELEASE CACHE STRING "")
# Stage 1 Bootstrap Setup
@@ -33,9 +36,17 @@ set(BOOTSTRAP_CLANG_BOOTSTRAP_TARGETS
check-clang CACHE STRING "")
# Stage 2 Options
-set(BOOTSTRAP_LLVM_ENABLE_PROJECTS "clang" CACHE STRING "")
+set(STAGE2_PROJECTS "clang")
+if (LLVM_RELEASE_ENABLE_LTO)
+ list(APPEND STAGE2_PROJECTS "lld")
+endif()
+set(BOOTSTRAP_LLVM_ENABLE_PROJECTS ${STAGE2_PROJECTS} CACHE STRING "")
set(BOOTSTRAP_LLVM_TARGETS_TO_BUILD Native CACHE STRING "")
# Stage 3 Options
set(BOOTSTRAP_BOOTSTRAP_LLVM_ENABLE_RUNTIMES
"compiler-rt;libcxx;libcxxabi;libunwind" CACHE STRING "")
set(BOOTSTRAP_BOOTSTRAP_LLVM_ENABLE_PROJECTS
"clang;lld;lldb;clang-tools-extra;bolt;polly;mlir;flang" CACHE STRING "")
+set(BOOTSTRAP_BOOTSTRAP_LLVM_ENABLE_LTO ${LLVM_RELEASE_ENABLE_LTO} CACHE
STRING "")
+if (LLVM_RELEASE_ENABLE_LTO)
+ set(BOOTSTRAP_BOOTSTRAP_LLVM_ENABLE_LLD ON CACHE BOOL "")
+endif()
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [CMake][Release] Add option for enabling LTO to cache file (PR #77035)
https://github.com/tstellar updated
https://github.com/llvm/llvm-project/pull/77035
>From db643899042aea45da93c1738b523f139f307295 Mon Sep 17 00:00:00 2001
From: Tom Stellard
Date: Fri, 5 Jan 2024 00:58:58 +
Subject: [PATCH 1/3] [CMake][Release] Add option for enabling LTO to cache
file
This option is LLVM_RELEASE_ENABLE_LTO and it's turned on by default.
---
clang/cmake/caches/Release.cmake | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/clang/cmake/caches/Release.cmake b/clang/cmake/caches/Release.cmake
index 3ea65ce26296c8..a7b9a8d0e29f88 100644
--- a/clang/cmake/caches/Release.cmake
+++ b/clang/cmake/caches/Release.cmake
@@ -2,6 +2,9 @@
# BOOTSTRAP_* options configure the second build.
# BOOTSTRAP_BOOTSTRAP_* options configure the third build.
+# General Options
+set(LLVM_RELEASE_ENABLE_LTO THIN CACHE STRING "")
+
set(CMAKE_BUILD_TYPE RELEASE CACHE STRING "")
# Stage 1 Bootstrap Setup
@@ -33,9 +36,17 @@ set(BOOTSTRAP_CLANG_BOOTSTRAP_TARGETS
check-clang CACHE STRING "")
# Stage 2 Options
-set(BOOTSTRAP_LLVM_ENABLE_PROJECTS "clang" CACHE STRING "")
+set(STAGE2_PROJECTS "clang")
+if (LLVM_RELEASE_ENABLE_LTO)
+ list(APPEND STAGE2_PROJECTS "lld")
+endif()
+set(BOOTSTRAP_LLVM_ENABLE_PROJECTS ${STAGE2_PROJECTS} CACHE STRING "")
set(BOOTSTRAP_LLVM_TARGETS_TO_BUILD Native CACHE STRING "")
# Stage 3 Options
set(BOOTSTRAP_BOOTSTRAP_LLVM_ENABLE_RUNTIMES
"compiler-rt;libcxx;libcxxabi;libunwind" CACHE STRING "")
set(BOOTSTRAP_BOOTSTRAP_LLVM_ENABLE_PROJECTS
"clang;lld;lldb;clang-tools-extra;bolt;polly;mlir;flang" CACHE STRING "")
+set(BOOTSTRAP_BOOTSTRAP_LLVM_ENABLE_LTO ${LLVM_RELEASE_ENABLE_LTO} CACHE
STRING "")
+if (LLVM_RELEASE_ENABLE_LTO)
+ set(BOOTSTRAP_BOOTSTRAP_LLVM_ENABLE_LLD ON CACHE BOOL "")
+endif()
>From b41c8bb2dda110674a2c1bdc4daf0ed88d69bfcb Mon Sep 17 00:00:00 2001
From: Tom Stellard
Date: Sat, 6 Jan 2024 06:44:32 +
Subject: [PATCH 2/3] XXX: test-release.sh pgo
---
clang/cmake/caches/Release.cmake | 77 +++---
llvm/utils/release/test-release.sh | 4 +-
2 files changed, 63 insertions(+), 18 deletions(-)
diff --git a/clang/cmake/caches/Release.cmake b/clang/cmake/caches/Release.cmake
index a7b9a8d0e29f88..1d8d5a7383ac37 100644
--- a/clang/cmake/caches/Release.cmake
+++ b/clang/cmake/caches/Release.cmake
@@ -4,27 +4,57 @@
# General Options
set(LLVM_RELEASE_ENABLE_LTO THIN CACHE STRING "")
+set(LLVM_RELEASE_ENABLE_PGO ON CACHE BOOL "")
set(CMAKE_BUILD_TYPE RELEASE CACHE STRING "")
# Stage 1 Bootstrap Setup
set(CLANG_ENABLE_BOOTSTRAP ON CACHE BOOL "")
-set(CLANG_BOOTSTRAP_TARGETS
- clang
- check-all
- check-llvm
- check-clang
- test-suite
- stage3
- stage3-clang
- stage3-check-all
- stage3-check-llvm
- stage3-check-clang
- stage3-install
- stage3-test-suite CACHE STRING "")
+if (LLVM_RELEASE_ENABLE_PGO)
+ set(CLANG_BOOTSTRAP_TARGETS
+generate-profdata
+stage2
+stage2-clang
+stage2-distribution
+stage2-install
+stage2-install-distribution
+stage2-install-distribution-toolchain
+stage2-check-all
+stage2-check-llvm
+stage2-check-clang
+stage2-test-suite CACHE STRING "")
+else()
+ set(CLANG_BOOTSTRAP_TARGETS
+clang
+check-all
+check-llvm
+check-clang
+test-suite
+stage3
+stage3-clang
+stage3-check-all
+stage3-check-llvm
+stage3-check-clang
+stage3-install
+stage3-test-suite CACHE STRING "")
+endif()
+
+if (LLVM_RELEASE_ENABLE_PGO)
+ list(INSERT CLANG_BOOTSTRAP_TARGETS 0 generate-profdata)
+endif()
# Stage 1 Options
-set(LLVM_ENABLE_PROJECTS "clang" CACHE STRING "")
+set(STAGE1_PROJECTS "clang")
+set(STAGE1_RUNTIMES "")
+
+if (LLVM_RELEASE_ENABLE_PGO)
+ list(APPEND STAGE1_PROJECTS "lld")
+ list(APPEND STAGE1_RUNTIMES "compiler-rt")
+endif()
+
+set(LLVM_ENABLE_RUNTIMES ${STAGE1_RUNTIMES} CACHE STRING "")
+set(LLVM_ENABLE_PROJECTS ${STAGE1_PROJECTS} CACHE STRING "")
+
set(LLVM_TARGETS_TO_BUILD Native CACHE STRING "")
# Stage 2 Bootstrap Setup
@@ -37,11 +67,26 @@ set(BOOTSTRAP_CLANG_BOOTSTRAP_TARGETS
# Stage 2 Options
set(STAGE2_PROJECTS "clang")
-if (LLVM_RELEASE_ENABLE_LTO)
+set(STAGE2_RUNTIMES "")
+
+if (LLVM_RELEASE_ENABLE_LTO OR LLVM_RELEASE_ENABLE_PGO)
list(APPEND STAGE2_PROJECTS "lld")
endif()
+
+if (LLVM_RELEASE_ENABLE_PGO)
+ set(BOOTSTRAP_LLVM_BUILD_INSTRUMENTED ON CACHE BOOL "")
+ list(APPEND STAGE2_RUTNIMES "compiler-rt")
+ set(BOOTSTRAP_LLVM_ENABLE_LTO ${LLVM_RELEASE_ENABLE_LTO})
+ if (LLVM_RELEASE_ENABLE_LTO)
+set(BOOTSTRAP_LLVM_ENABLE_LLD ON CACHE BOOL "")
+ endif()
+endif()
+
set(BOOTSTRAP_LLVM_ENABLE_PROJECTS ${STAGE2_PROJECTS} CACHE STRING "")
-set(BOOTSTRAP_LLVM_TARGETS_TO_BUILD Native CACHE STRING "")
+set(BOOTSTRAP_LLVM_ENABLE_RUNTIMES ${STAGE2_RUNTIMES} CACHE STRING "")
+if (NOT LLVM_RELEASE_PGO)
+ set(BOOTSTRAP_LLVM_TARGETS_TO_BUILD Native CACHE STRING "")
+endif()
# Stage 3 Options
set(BOOTSTRAP_BOOTSTRAP_LLVM_ENABLE_RUNTIMES
[clang] [CMake][Release] Add option for enabling LTO to cache file (PR #77035)
https://github.com/tstellar created
https://github.com/llvm/llvm-project/pull/77035
This option is LLVM_RELEASE_ENABLE_LTO and it's turned on by default.
>From db643899042aea45da93c1738b523f139f307295 Mon Sep 17 00:00:00 2001
From: Tom Stellard
Date: Fri, 5 Jan 2024 00:58:58 +
Subject: [PATCH] [CMake][Release] Add option for enabling LTO to cache file
This option is LLVM_RELEASE_ENABLE_LTO and it's turned on by default.
---
clang/cmake/caches/Release.cmake | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/clang/cmake/caches/Release.cmake b/clang/cmake/caches/Release.cmake
index 3ea65ce26296c8..a7b9a8d0e29f88 100644
--- a/clang/cmake/caches/Release.cmake
+++ b/clang/cmake/caches/Release.cmake
@@ -2,6 +2,9 @@
# BOOTSTRAP_* options configure the second build.
# BOOTSTRAP_BOOTSTRAP_* options configure the third build.
+# General Options
+set(LLVM_RELEASE_ENABLE_LTO THIN CACHE STRING "")
+
set(CMAKE_BUILD_TYPE RELEASE CACHE STRING "")
# Stage 1 Bootstrap Setup
@@ -33,9 +36,17 @@ set(BOOTSTRAP_CLANG_BOOTSTRAP_TARGETS
check-clang CACHE STRING "")
# Stage 2 Options
-set(BOOTSTRAP_LLVM_ENABLE_PROJECTS "clang" CACHE STRING "")
+set(STAGE2_PROJECTS "clang")
+if (LLVM_RELEASE_ENABLE_LTO)
+ list(APPEND STAGE2_PROJECTS "lld")
+endif()
+set(BOOTSTRAP_LLVM_ENABLE_PROJECTS ${STAGE2_PROJECTS} CACHE STRING "")
set(BOOTSTRAP_LLVM_TARGETS_TO_BUILD Native CACHE STRING "")
# Stage 3 Options
set(BOOTSTRAP_BOOTSTRAP_LLVM_ENABLE_RUNTIMES
"compiler-rt;libcxx;libcxxabi;libunwind" CACHE STRING "")
set(BOOTSTRAP_BOOTSTRAP_LLVM_ENABLE_PROJECTS
"clang;lld;lldb;clang-tools-extra;bolt;polly;mlir;flang" CACHE STRING "")
+set(BOOTSTRAP_BOOTSTRAP_LLVM_ENABLE_LTO ${LLVM_RELEASE_ENABLE_LTO} CACHE
STRING "")
+if (LLVM_RELEASE_ENABLE_LTO)
+ set(BOOTSTRAP_BOOTSTRAP_LLVM_ENABLE_LLD ON CACHE BOOL "")
+endif()
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] test-release.sh: Add a CMake cache file for 3-stage release builds (PR #75903)
https://github.com/tstellar closed https://github.com/llvm/llvm-project/pull/75903 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Driver] Add the --gcc-triple option (PR #73214)
tstellar wrote: @MaskRay Do these tests look OK now? https://github.com/llvm/llvm-project/pull/73214 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[llvm] [clang] test-release.sh: Add a CMake cache file for 3-stage release builds (PR #75903)
https://github.com/tstellar updated
https://github.com/llvm/llvm-project/pull/75903
>From 88b9aac241bed0ce7c65fa798b68c9779f0615e7 Mon Sep 17 00:00:00 2001
From: Tom Stellard
Date: Fri, 15 Dec 2023 01:27:25 +
Subject: [PATCH 1/2] test-release.sh: Add a CMake cache file for 3-stage
release builds
You can now pass the -use-cmake-cache option and it will use a
predefined cache file for building the release. This will make it
easier to reproduce the builds and add other enhancements, like PGO
or bolt optimizations.
---
.github/workflows/release-binaries.yml | 5 +-
clang/cmake/caches/Release.cmake | 41
llvm/utils/release/test-release.sh | 67 +++---
3 files changed, 104 insertions(+), 9 deletions(-)
create mode 100644 clang/cmake/caches/Release.cmake
diff --git a/.github/workflows/release-binaries.yml
b/.github/workflows/release-binaries.yml
index 4e3eaff97a8783..4a4ba9dcc5ca34 100644
--- a/.github/workflows/release-binaries.yml
+++ b/.github/workflows/release-binaries.yml
@@ -93,8 +93,8 @@ jobs:
- name: Build Clang
run: |
-cmake -G Ninja -DCMAKE_C_COMPILER_LAUNCHER=sccache
-DCMAKE_CXX_COMPILER_LAUNCHER=sccache -DCMAKE_BUILD_TYPE=Release
-DCMAKE_ENABLE_ASSERTIONS=OFF -DCMAKE_POSITION_INDEPENDENT_CODE=ON
-DLLVM_ENABLE_PROJECTS=clang -S llvm -B build
-ninja -v -C build
+cmake -G Ninja -C clang/cmake/caches/Release.cmake
-DCMAKE_C_COMPILER_LAUNCHER=sccache -DCMAKE_CXX_COMPILER_LAUNCHER=sccache
-DCMAKE_POSITION_INDEPENDENT_CODE=ON -S llvm -B build
+ninja -v -C build clang
build-binaries:
@@ -152,6 +152,7 @@ jobs:
-triple ${{ matrix.target.triple }} \
-use-ninja \
-no-checkout \
+-use-cmake-cache \
-no-test-suite \
-configure-flags "-DCMAKE_C_COMPILER_LAUNCHER=sccache
-DCMAKE_CXX_COMPILER_LAUNCHER=sccache"
diff --git a/clang/cmake/caches/Release.cmake b/clang/cmake/caches/Release.cmake
new file mode 100644
index 00..42c88655c58cee
--- /dev/null
+++ b/clang/cmake/caches/Release.cmake
@@ -0,0 +1,41 @@
+# Plain options configure the first build.
+# BOOTSTRAP_* options configure the second build.
+# BOOTSTRAP_BOOTSTRAP_* options configure the third build.
+
+set(CMAKE_BUILD_TYPE RELEASE CACHE STRING "")
+
+# Stage 1 Bootstrap Setup
+set(CLANG_ENABLE_BOOTSTRAP ON CACHE BOOL "")
+set(CLANG_BOOTSTRAP_TARGETS
+ clang
+ check-all
+ check-llvm
+ check-clang
+ test-suite
+ stage3
+ stage3-clang
+ stage3-check-all
+ stage3-check-llvm
+ stage3-check-clang
+ stage3-install
+ stage3-test-suite CACHE STRING "")
+
+# Stage 1 Options
+set(LLVM_ENABLE_PROJECTS "clang" CACHE STRING "")
+set(LLVM_TARGETS_TO_BUILD Native CACHE STRING "")
+
+# Stage 2 Bootstrap Setup
+set(BOOTSTRAP_CLANG_ENABLE_BOOTSTRAP=ON CACHE STRING "")
+set(BOOTSTRAP_CLANG_BOOTSTRAP_TARGETS
+ clang
+ check-all
+ check-llvm
+ check-clang CACHE STRING "")
+
+# Stage 2 Options
+set(BOOTSTRAP_LLVM_ENABLE_PROJECTS "clang" CACHE STRING "")
+set(BOOTSTRAP_LLVM_TARGETS_TO_BUILD Native CACHE STRING "")
+
+# Stage 3 Options
+set(BOOTSTRAP_BOOTSTRAP_LLVM_ENABLE_RUNTIMES
"compiler-rt;libcxx;libcxxabi;libunwind" CACHE STRING "")
+set(BOOTSTRAP_BOOTSTRAP_LLVM_ENABLE_PROJECTS
"clang;lld;lldb;clang-tools-extra;bolt;polly;mlir;flang" CACHE STRING "")
diff --git a/llvm/utils/release/test-release.sh
b/llvm/utils/release/test-release.sh
index f38134e3d22d8f..544d4bfdd799ce 100755
--- a/llvm/utils/release/test-release.sh
+++ b/llvm/utils/release/test-release.sh
@@ -46,7 +46,7 @@ BuildDir="`pwd`"
ExtraConfigureFlags=""
ExportBranch=""
git_ref=""
-
+do_cmake_cache="no"
do_bolt="no"
if [ "$System" = "Linux" ]; then
case $Machine in
@@ -87,6 +87,7 @@ function usage() {
echo " -no-mlir Disable check-out & build MLIR"
echo " -no-flangDisable check-out & build Flang"
echo " -silent-log Don't output build logs to stdout"
+echo " -use-cmake-cache Build using a CMake cache file"
}
while [ $# -gt 0 ]; do
@@ -200,6 +201,9 @@ while [ $# -gt 0 ]; do
-silent-log )
do_silent_log="yes"
;;
+-use-cmake-cache | --use-cmake-cache )
+do_cmake_cache="yes"
+;;
-help | --help | -h | --h | -\? )
usage
exit 0
@@ -328,6 +332,55 @@ Package=$Package-$Triple
# Errors to be highlighted at the end are written to this file.
echo -n > $LogDir/deferred_errors.log
+redir="/dev/stdout"
+if [ $do_silent_log == "yes" ]; then
+ echo "# Silencing build logs because of -silent-log flag..."
+ redir="/dev/null"
+fi
+
+
+function build_with_cmake_cache() {
+(
+ CMakeBuildDir=$BuildDir/build
+ SrcDir=$BuildDir/llvm-project/
+ InstallDir=$BuildDir/install
+
+ rm -rf $CMakeBuildDir
+
+ # FIXME: Would be nice if the commands were echoed to the log file too.
+ set -x
+
+ env CC="$c_compiler" CXX="$cxx_compiler" \
+ cmake -G "$generator" -B
[clang] [llvm] test-release.sh: Add a CMake cache file for 3-stage release builds (PR #75903)
tstellar wrote: > Out of curiosity, what's the reason for using 3-stage (rather than 2-stage) > build? I'm trying to replicate what the script currently does which is a 3-stage build. I also want to add in PGO in the future, which would require 3 stages. https://github.com/llvm/llvm-project/pull/75903 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] test-release.sh: Add a CMake cache file for 3-stage release builds (PR #75903)
https://github.com/tstellar created
https://github.com/llvm/llvm-project/pull/75903
You can now pass the -use-cmake-cache option to test-release.sh and it will use
a predefined cache file for building the release. This will make it easier to
reproduce the builds and add other enhancements like PGO or bolt optimizations.
>From 88b9aac241bed0ce7c65fa798b68c9779f0615e7 Mon Sep 17 00:00:00 2001
From: Tom Stellard
Date: Fri, 15 Dec 2023 01:27:25 +
Subject: [PATCH] test-release.sh: Add a CMake cache file for 3-stage release
builds
You can now pass the -use-cmake-cache option and it will use a
predefined cache file for building the release. This will make it
easier to reproduce the builds and add other enhancements, like PGO
or bolt optimizations.
---
.github/workflows/release-binaries.yml | 5 +-
clang/cmake/caches/Release.cmake | 41
llvm/utils/release/test-release.sh | 67 +++---
3 files changed, 104 insertions(+), 9 deletions(-)
create mode 100644 clang/cmake/caches/Release.cmake
diff --git a/.github/workflows/release-binaries.yml
b/.github/workflows/release-binaries.yml
index 4e3eaff97a8783..4a4ba9dcc5ca34 100644
--- a/.github/workflows/release-binaries.yml
+++ b/.github/workflows/release-binaries.yml
@@ -93,8 +93,8 @@ jobs:
- name: Build Clang
run: |
-cmake -G Ninja -DCMAKE_C_COMPILER_LAUNCHER=sccache
-DCMAKE_CXX_COMPILER_LAUNCHER=sccache -DCMAKE_BUILD_TYPE=Release
-DCMAKE_ENABLE_ASSERTIONS=OFF -DCMAKE_POSITION_INDEPENDENT_CODE=ON
-DLLVM_ENABLE_PROJECTS=clang -S llvm -B build
-ninja -v -C build
+cmake -G Ninja -C clang/cmake/caches/Release.cmake
-DCMAKE_C_COMPILER_LAUNCHER=sccache -DCMAKE_CXX_COMPILER_LAUNCHER=sccache
-DCMAKE_POSITION_INDEPENDENT_CODE=ON -S llvm -B build
+ninja -v -C build clang
build-binaries:
@@ -152,6 +152,7 @@ jobs:
-triple ${{ matrix.target.triple }} \
-use-ninja \
-no-checkout \
+-use-cmake-cache \
-no-test-suite \
-configure-flags "-DCMAKE_C_COMPILER_LAUNCHER=sccache
-DCMAKE_CXX_COMPILER_LAUNCHER=sccache"
diff --git a/clang/cmake/caches/Release.cmake b/clang/cmake/caches/Release.cmake
new file mode 100644
index 00..42c88655c58cee
--- /dev/null
+++ b/clang/cmake/caches/Release.cmake
@@ -0,0 +1,41 @@
+# Plain options configure the first build.
+# BOOTSTRAP_* options configure the second build.
+# BOOTSTRAP_BOOTSTRAP_* options configure the third build.
+
+set(CMAKE_BUILD_TYPE RELEASE CACHE STRING "")
+
+# Stage 1 Bootstrap Setup
+set(CLANG_ENABLE_BOOTSTRAP ON CACHE BOOL "")
+set(CLANG_BOOTSTRAP_TARGETS
+ clang
+ check-all
+ check-llvm
+ check-clang
+ test-suite
+ stage3
+ stage3-clang
+ stage3-check-all
+ stage3-check-llvm
+ stage3-check-clang
+ stage3-install
+ stage3-test-suite CACHE STRING "")
+
+# Stage 1 Options
+set(LLVM_ENABLE_PROJECTS "clang" CACHE STRING "")
+set(LLVM_TARGETS_TO_BUILD Native CACHE STRING "")
+
+# Stage 2 Bootstrap Setup
+set(BOOTSTRAP_CLANG_ENABLE_BOOTSTRAP=ON CACHE STRING "")
+set(BOOTSTRAP_CLANG_BOOTSTRAP_TARGETS
+ clang
+ check-all
+ check-llvm
+ check-clang CACHE STRING "")
+
+# Stage 2 Options
+set(BOOTSTRAP_LLVM_ENABLE_PROJECTS "clang" CACHE STRING "")
+set(BOOTSTRAP_LLVM_TARGETS_TO_BUILD Native CACHE STRING "")
+
+# Stage 3 Options
+set(BOOTSTRAP_BOOTSTRAP_LLVM_ENABLE_RUNTIMES
"compiler-rt;libcxx;libcxxabi;libunwind" CACHE STRING "")
+set(BOOTSTRAP_BOOTSTRAP_LLVM_ENABLE_PROJECTS
"clang;lld;lldb;clang-tools-extra;bolt;polly;mlir;flang" CACHE STRING "")
diff --git a/llvm/utils/release/test-release.sh
b/llvm/utils/release/test-release.sh
index f38134e3d22d8f..544d4bfdd799ce 100755
--- a/llvm/utils/release/test-release.sh
+++ b/llvm/utils/release/test-release.sh
@@ -46,7 +46,7 @@ BuildDir="`pwd`"
ExtraConfigureFlags=""
ExportBranch=""
git_ref=""
-
+do_cmake_cache="no"
do_bolt="no"
if [ "$System" = "Linux" ]; then
case $Machine in
@@ -87,6 +87,7 @@ function usage() {
echo " -no-mlir Disable check-out & build MLIR"
echo " -no-flangDisable check-out & build Flang"
echo " -silent-log Don't output build logs to stdout"
+echo " -use-cmake-cache Build using a CMake cache file"
}
while [ $# -gt 0 ]; do
@@ -200,6 +201,9 @@ while [ $# -gt 0 ]; do
-silent-log )
do_silent_log="yes"
;;
+-use-cmake-cache | --use-cmake-cache )
+do_cmake_cache="yes"
+;;
-help | --help | -h | --h | -\? )
usage
exit 0
@@ -328,6 +332,55 @@ Package=$Package-$Triple
# Errors to be highlighted at the end are written to this file.
echo -n > $LogDir/deferred_errors.log
+redir="/dev/stdout"
+if [ $do_silent_log == "yes" ]; then
+ echo "# Silencing build logs because of -silent-log flag..."
+ redir="/dev/null"
+fi
+
+
+function build_with_cmake_cache() {
+(
+ CMakeBuildDir=$BuildDir/build
+
[clang] Driver: Accept the --gcc-install-dir option multiple times (PR #71446)
https://github.com/tstellar closed https://github.com/llvm/llvm-project/pull/71446 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] Driver: Accept the --gcc-install-dir option multiple times (PR #71446)
tstellar wrote: Closing in favor of #73214 . https://github.com/llvm/llvm-project/pull/71446 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Driver] Add the --gcc-triple option (PR #73214)
https://github.com/tstellar updated
https://github.com/llvm/llvm-project/pull/73214
>From 72f6f3a611f237f71ce02cfb79620257a9e2d827 Mon Sep 17 00:00:00 2001
From: Tom Stellard
Date: Thu, 16 Nov 2023 05:11:04 +
Subject: [PATCH 1/7] [Driver] Add the --gcc-triple option
When --gcc-triple is used, the driver will search for the 'best' gcc
installation that has the given triple. This is useful for
distributions that want clang to use a specific gcc triple, but do
not want to pin to a specific version as would be required by
using --gcc-install-dir. Having clang linked to a specific gcc version
can cause clang to stop working when the version of gcc installed on
the system gets updated.
---
clang/include/clang/Driver/Options.td | 2 ++
clang/lib/Driver/ToolChains/Gnu.cpp | 8
.../usr/lib/gcc/x86_64-linux-gnu/13/crtbegin.o| 0
.../usr/lib/gcc/x86_64-linux-gnu/13/crtend.o | 0
.../fedora_39_tree/usr/lib/gcc/x86_64-linux-gnu/13/crti.o | 0
.../fedora_39_tree/usr/lib/gcc/x86_64-linux-gnu/13/crtn.o | 0
.../usr/lib/gcc/x86_64-redhat-linux/13/crtbegin.o | 0
.../usr/lib/gcc/x86_64-redhat-linux/13/crtend.o | 0
.../usr/lib/gcc/x86_64-redhat-linux/13/crti.o | 0
.../usr/lib/gcc/x86_64-redhat-linux/13/crtn.o | 0
clang/test/Driver/gcc-prefix.cpp | 8
11 files changed, 18 insertions(+)
create mode 100644
clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-linux-gnu/13/crtbegin.o
create mode 100644
clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-linux-gnu/13/crtend.o
create mode 100644
clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-linux-gnu/13/crti.o
create mode 100644
clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-linux-gnu/13/crtn.o
create mode 100644
clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-redhat-linux/13/crtbegin.o
create mode 100644
clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-redhat-linux/13/crtend.o
create mode 100644
clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-redhat-linux/13/crti.o
create mode 100644
clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-redhat-linux/13/crtn.o
create mode 100644 clang/test/Driver/gcc-prefix.cpp
diff --git a/clang/include/clang/Driver/Options.td
b/clang/include/clang/Driver/Options.td
index b2f2bcb6ac3791..79ced47150b455 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -773,6 +773,8 @@ def gcc_install_dir_EQ : Joined<["--"], "gcc-install-dir=">,
def gcc_toolchain : Joined<["--"], "gcc-toolchain=">, Flags<[NoXarchOption]>,
HelpText<"Specify a directory where Clang can find 'include' and
'lib{,32,64}/gcc{,-cross}/$triple/$version'. "
"Clang will use the GCC installation with the largest version">;
+def gcc_triple_EQ : Joined<["--"], "gcc-triple=">,
+ HelpText<"Search for the GCC installation with the specified triple.">;
def CC : Flag<["-"], "CC">, Visibility<[ClangOption, CC1Option]>,
Group,
HelpText<"Include comments from within macros in preprocessed output">,
diff --git a/clang/lib/Driver/ToolChains/Gnu.cpp
b/clang/lib/Driver/ToolChains/Gnu.cpp
index 9fb99145d3b909..44b92a879a3a8c 100644
--- a/clang/lib/Driver/ToolChains/Gnu.cpp
+++ b/clang/lib/Driver/ToolChains/Gnu.cpp
@@ -2130,6 +2130,14 @@ void Generic_GCC::GCCInstallationDetector::init(
return;
}
+ // If --gcc-triple is specified use this instead of trying to
+ // auto-detect a triple.
+ if (const Arg *A =
Args.getLastArg(clang::driver::options::OPT_gcc_triple_EQ)) {
+StringRef GCCTriple = A->getValue();
+CandidateTripleAliases.clear();
+CandidateTripleAliases.push_back(GCCTriple);
+ }
+
// Compute the set of prefixes for our search.
SmallVector Prefixes;
StringRef GCCToolchainDir = getGCCToolchainDir(Args, D.SysRoot);
diff --git
a/clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-linux-gnu/13/crtbegin.o
b/clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-linux-gnu/13/crtbegin.o
new file mode 100644
index 00..e69de29bb2d1d6
diff --git
a/clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-linux-gnu/13/crtend.o
b/clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-linux-gnu/13/crtend.o
new file mode 100644
index 00..e69de29bb2d1d6
diff --git
a/clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-linux-gnu/13/crti.o
b/clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-linux-gnu/13/crti.o
new file mode 100644
index 00..e69de29bb2d1d6
diff --git
a/clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-linux-gnu/13/crtn.o
b/clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-linux-gnu/13/crtn.o
new file mode 100644
index 00..e69de29bb2d1d6
diff --git
a/clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-redhat-linux/13/crtbegin.o
[clang] [Driver] Add the --gcc-triple option (PR #73214)
https://github.com/tstellar updated
https://github.com/llvm/llvm-project/pull/73214
>From 72f6f3a611f237f71ce02cfb79620257a9e2d827 Mon Sep 17 00:00:00 2001
From: Tom Stellard
Date: Thu, 16 Nov 2023 05:11:04 +
Subject: [PATCH 1/6] [Driver] Add the --gcc-triple option
When --gcc-triple is used, the driver will search for the 'best' gcc
installation that has the given triple. This is useful for
distributions that want clang to use a specific gcc triple, but do
not want to pin to a specific version as would be required by
using --gcc-install-dir. Having clang linked to a specific gcc version
can cause clang to stop working when the version of gcc installed on
the system gets updated.
---
clang/include/clang/Driver/Options.td | 2 ++
clang/lib/Driver/ToolChains/Gnu.cpp | 8
.../usr/lib/gcc/x86_64-linux-gnu/13/crtbegin.o| 0
.../usr/lib/gcc/x86_64-linux-gnu/13/crtend.o | 0
.../fedora_39_tree/usr/lib/gcc/x86_64-linux-gnu/13/crti.o | 0
.../fedora_39_tree/usr/lib/gcc/x86_64-linux-gnu/13/crtn.o | 0
.../usr/lib/gcc/x86_64-redhat-linux/13/crtbegin.o | 0
.../usr/lib/gcc/x86_64-redhat-linux/13/crtend.o | 0
.../usr/lib/gcc/x86_64-redhat-linux/13/crti.o | 0
.../usr/lib/gcc/x86_64-redhat-linux/13/crtn.o | 0
clang/test/Driver/gcc-prefix.cpp | 8
11 files changed, 18 insertions(+)
create mode 100644
clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-linux-gnu/13/crtbegin.o
create mode 100644
clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-linux-gnu/13/crtend.o
create mode 100644
clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-linux-gnu/13/crti.o
create mode 100644
clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-linux-gnu/13/crtn.o
create mode 100644
clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-redhat-linux/13/crtbegin.o
create mode 100644
clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-redhat-linux/13/crtend.o
create mode 100644
clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-redhat-linux/13/crti.o
create mode 100644
clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-redhat-linux/13/crtn.o
create mode 100644 clang/test/Driver/gcc-prefix.cpp
diff --git a/clang/include/clang/Driver/Options.td
b/clang/include/clang/Driver/Options.td
index b2f2bcb6ac3791..79ced47150b455 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -773,6 +773,8 @@ def gcc_install_dir_EQ : Joined<["--"], "gcc-install-dir=">,
def gcc_toolchain : Joined<["--"], "gcc-toolchain=">, Flags<[NoXarchOption]>,
HelpText<"Specify a directory where Clang can find 'include' and
'lib{,32,64}/gcc{,-cross}/$triple/$version'. "
"Clang will use the GCC installation with the largest version">;
+def gcc_triple_EQ : Joined<["--"], "gcc-triple=">,
+ HelpText<"Search for the GCC installation with the specified triple.">;
def CC : Flag<["-"], "CC">, Visibility<[ClangOption, CC1Option]>,
Group,
HelpText<"Include comments from within macros in preprocessed output">,
diff --git a/clang/lib/Driver/ToolChains/Gnu.cpp
b/clang/lib/Driver/ToolChains/Gnu.cpp
index 9fb99145d3b909..44b92a879a3a8c 100644
--- a/clang/lib/Driver/ToolChains/Gnu.cpp
+++ b/clang/lib/Driver/ToolChains/Gnu.cpp
@@ -2130,6 +2130,14 @@ void Generic_GCC::GCCInstallationDetector::init(
return;
}
+ // If --gcc-triple is specified use this instead of trying to
+ // auto-detect a triple.
+ if (const Arg *A =
Args.getLastArg(clang::driver::options::OPT_gcc_triple_EQ)) {
+StringRef GCCTriple = A->getValue();
+CandidateTripleAliases.clear();
+CandidateTripleAliases.push_back(GCCTriple);
+ }
+
// Compute the set of prefixes for our search.
SmallVector Prefixes;
StringRef GCCToolchainDir = getGCCToolchainDir(Args, D.SysRoot);
diff --git
a/clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-linux-gnu/13/crtbegin.o
b/clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-linux-gnu/13/crtbegin.o
new file mode 100644
index 00..e69de29bb2d1d6
diff --git
a/clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-linux-gnu/13/crtend.o
b/clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-linux-gnu/13/crtend.o
new file mode 100644
index 00..e69de29bb2d1d6
diff --git
a/clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-linux-gnu/13/crti.o
b/clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-linux-gnu/13/crti.o
new file mode 100644
index 00..e69de29bb2d1d6
diff --git
a/clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-linux-gnu/13/crtn.o
b/clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-linux-gnu/13/crtn.o
new file mode 100644
index 00..e69de29bb2d1d6
diff --git
a/clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-redhat-linux/13/crtbegin.o
[clang] [Driver] Add the --gcc-triple option (PR #73214)
@@ -2130,6 +2130,15 @@ void Generic_GCC::GCCInstallationDetector::init(
return;
}
+ // If --gcc-triple is specified use this instead of trying to
+ // auto-detect a triple.
+ if (const Arg *A =
+ Args.getLastArg(clang::driver::options::OPT_gcc_triple_EQ)) {
+StringRef GCCTriple = A->getValue();
+CandidateTripleAliases.clear();
+CandidateTripleAliases.push_back(GCCTriple);
+ }
+
// Compute the set of prefixes for our search.
tstellar wrote:
No --gcc-toolchain= and GCC_INSTALL_PREFIX should be unaffected. They just
provide the install prefix and then --gcc-triple specifies the triple to use
within that prefix.
I think GCC_INSTALL_PREFIX should be deprecated still because this
functionality can be replicated using config files now.
https://github.com/llvm/llvm-project/pull/73214
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Driver] Add the --gcc-triple option (PR #73214)
https://github.com/tstellar updated
https://github.com/llvm/llvm-project/pull/73214
>From 72f6f3a611f237f71ce02cfb79620257a9e2d827 Mon Sep 17 00:00:00 2001
From: Tom Stellard
Date: Thu, 16 Nov 2023 05:11:04 +
Subject: [PATCH 1/2] [Driver] Add the --gcc-triple option
When --gcc-triple is used, the driver will search for the 'best' gcc
installation that has the given triple. This is useful for
distributions that want clang to use a specific gcc triple, but do
not want to pin to a specific version as would be required by
using --gcc-install-dir. Having clang linked to a specific gcc version
can cause clang to stop working when the version of gcc installed on
the system gets updated.
---
clang/include/clang/Driver/Options.td | 2 ++
clang/lib/Driver/ToolChains/Gnu.cpp | 8
.../usr/lib/gcc/x86_64-linux-gnu/13/crtbegin.o| 0
.../usr/lib/gcc/x86_64-linux-gnu/13/crtend.o | 0
.../fedora_39_tree/usr/lib/gcc/x86_64-linux-gnu/13/crti.o | 0
.../fedora_39_tree/usr/lib/gcc/x86_64-linux-gnu/13/crtn.o | 0
.../usr/lib/gcc/x86_64-redhat-linux/13/crtbegin.o | 0
.../usr/lib/gcc/x86_64-redhat-linux/13/crtend.o | 0
.../usr/lib/gcc/x86_64-redhat-linux/13/crti.o | 0
.../usr/lib/gcc/x86_64-redhat-linux/13/crtn.o | 0
clang/test/Driver/gcc-prefix.cpp | 8
11 files changed, 18 insertions(+)
create mode 100644
clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-linux-gnu/13/crtbegin.o
create mode 100644
clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-linux-gnu/13/crtend.o
create mode 100644
clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-linux-gnu/13/crti.o
create mode 100644
clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-linux-gnu/13/crtn.o
create mode 100644
clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-redhat-linux/13/crtbegin.o
create mode 100644
clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-redhat-linux/13/crtend.o
create mode 100644
clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-redhat-linux/13/crti.o
create mode 100644
clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-redhat-linux/13/crtn.o
create mode 100644 clang/test/Driver/gcc-prefix.cpp
diff --git a/clang/include/clang/Driver/Options.td
b/clang/include/clang/Driver/Options.td
index b2f2bcb6ac37910..79ced47150b455d 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -773,6 +773,8 @@ def gcc_install_dir_EQ : Joined<["--"], "gcc-install-dir=">,
def gcc_toolchain : Joined<["--"], "gcc-toolchain=">, Flags<[NoXarchOption]>,
HelpText<"Specify a directory where Clang can find 'include' and
'lib{,32,64}/gcc{,-cross}/$triple/$version'. "
"Clang will use the GCC installation with the largest version">;
+def gcc_triple_EQ : Joined<["--"], "gcc-triple=">,
+ HelpText<"Search for the GCC installation with the specified triple.">;
def CC : Flag<["-"], "CC">, Visibility<[ClangOption, CC1Option]>,
Group,
HelpText<"Include comments from within macros in preprocessed output">,
diff --git a/clang/lib/Driver/ToolChains/Gnu.cpp
b/clang/lib/Driver/ToolChains/Gnu.cpp
index 9fb99145d3b909e..44b92a879a3a8c1 100644
--- a/clang/lib/Driver/ToolChains/Gnu.cpp
+++ b/clang/lib/Driver/ToolChains/Gnu.cpp
@@ -2130,6 +2130,14 @@ void Generic_GCC::GCCInstallationDetector::init(
return;
}
+ // If --gcc-triple is specified use this instead of trying to
+ // auto-detect a triple.
+ if (const Arg *A =
Args.getLastArg(clang::driver::options::OPT_gcc_triple_EQ)) {
+StringRef GCCTriple = A->getValue();
+CandidateTripleAliases.clear();
+CandidateTripleAliases.push_back(GCCTriple);
+ }
+
// Compute the set of prefixes for our search.
SmallVector Prefixes;
StringRef GCCToolchainDir = getGCCToolchainDir(Args, D.SysRoot);
diff --git
a/clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-linux-gnu/13/crtbegin.o
b/clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-linux-gnu/13/crtbegin.o
new file mode 100644
index 000..e69de29bb2d1d64
diff --git
a/clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-linux-gnu/13/crtend.o
b/clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-linux-gnu/13/crtend.o
new file mode 100644
index 000..e69de29bb2d1d64
diff --git
a/clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-linux-gnu/13/crti.o
b/clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-linux-gnu/13/crti.o
new file mode 100644
index 000..e69de29bb2d1d64
diff --git
a/clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-linux-gnu/13/crtn.o
b/clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-linux-gnu/13/crtn.o
new file mode 100644
index 000..e69de29bb2d1d64
diff --git
[clang] [Driver] Add the --gcc-triple option (PR #73214)
https://github.com/tstellar created
https://github.com/llvm/llvm-project/pull/73214
When --gcc-triple is used, the driver will search for the 'best' gcc
installation that has the given triple. This is useful for distributions that
want clang to use a specific gcc triple, but do not want to pin to a specific
version as would be required by using --gcc-install-dir. Having clang linked
to a specific gcc version can cause clang to stop working when the version of
gcc installed on the system gets updated.
>From 72f6f3a611f237f71ce02cfb79620257a9e2d827 Mon Sep 17 00:00:00 2001
From: Tom Stellard
Date: Thu, 16 Nov 2023 05:11:04 +
Subject: [PATCH] [Driver] Add the --gcc-triple option
When --gcc-triple is used, the driver will search for the 'best' gcc
installation that has the given triple. This is useful for
distributions that want clang to use a specific gcc triple, but do
not want to pin to a specific version as would be required by
using --gcc-install-dir. Having clang linked to a specific gcc version
can cause clang to stop working when the version of gcc installed on
the system gets updated.
---
clang/include/clang/Driver/Options.td | 2 ++
clang/lib/Driver/ToolChains/Gnu.cpp | 8
.../usr/lib/gcc/x86_64-linux-gnu/13/crtbegin.o| 0
.../usr/lib/gcc/x86_64-linux-gnu/13/crtend.o | 0
.../fedora_39_tree/usr/lib/gcc/x86_64-linux-gnu/13/crti.o | 0
.../fedora_39_tree/usr/lib/gcc/x86_64-linux-gnu/13/crtn.o | 0
.../usr/lib/gcc/x86_64-redhat-linux/13/crtbegin.o | 0
.../usr/lib/gcc/x86_64-redhat-linux/13/crtend.o | 0
.../usr/lib/gcc/x86_64-redhat-linux/13/crti.o | 0
.../usr/lib/gcc/x86_64-redhat-linux/13/crtn.o | 0
clang/test/Driver/gcc-prefix.cpp | 8
11 files changed, 18 insertions(+)
create mode 100644
clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-linux-gnu/13/crtbegin.o
create mode 100644
clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-linux-gnu/13/crtend.o
create mode 100644
clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-linux-gnu/13/crti.o
create mode 100644
clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-linux-gnu/13/crtn.o
create mode 100644
clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-redhat-linux/13/crtbegin.o
create mode 100644
clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-redhat-linux/13/crtend.o
create mode 100644
clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-redhat-linux/13/crti.o
create mode 100644
clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-redhat-linux/13/crtn.o
create mode 100644 clang/test/Driver/gcc-prefix.cpp
diff --git a/clang/include/clang/Driver/Options.td
b/clang/include/clang/Driver/Options.td
index b2f2bcb6ac37910..79ced47150b455d 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -773,6 +773,8 @@ def gcc_install_dir_EQ : Joined<["--"], "gcc-install-dir=">,
def gcc_toolchain : Joined<["--"], "gcc-toolchain=">, Flags<[NoXarchOption]>,
HelpText<"Specify a directory where Clang can find 'include' and
'lib{,32,64}/gcc{,-cross}/$triple/$version'. "
"Clang will use the GCC installation with the largest version">;
+def gcc_triple_EQ : Joined<["--"], "gcc-triple=">,
+ HelpText<"Search for the GCC installation with the specified triple.">;
def CC : Flag<["-"], "CC">, Visibility<[ClangOption, CC1Option]>,
Group,
HelpText<"Include comments from within macros in preprocessed output">,
diff --git a/clang/lib/Driver/ToolChains/Gnu.cpp
b/clang/lib/Driver/ToolChains/Gnu.cpp
index 9fb99145d3b909e..44b92a879a3a8c1 100644
--- a/clang/lib/Driver/ToolChains/Gnu.cpp
+++ b/clang/lib/Driver/ToolChains/Gnu.cpp
@@ -2130,6 +2130,14 @@ void Generic_GCC::GCCInstallationDetector::init(
return;
}
+ // If --gcc-triple is specified use this instead of trying to
+ // auto-detect a triple.
+ if (const Arg *A =
Args.getLastArg(clang::driver::options::OPT_gcc_triple_EQ)) {
+StringRef GCCTriple = A->getValue();
+CandidateTripleAliases.clear();
+CandidateTripleAliases.push_back(GCCTriple);
+ }
+
// Compute the set of prefixes for our search.
SmallVector Prefixes;
StringRef GCCToolchainDir = getGCCToolchainDir(Args, D.SysRoot);
diff --git
a/clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-linux-gnu/13/crtbegin.o
b/clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-linux-gnu/13/crtbegin.o
new file mode 100644
index 000..e69de29bb2d1d64
diff --git
a/clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-linux-gnu/13/crtend.o
b/clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-linux-gnu/13/crtend.o
new file mode 100644
index 000..e69de29bb2d1d64
diff --git
a/clang/test/Driver/Inputs/fedora_39_tree/usr/lib/gcc/x86_64-linux-gnu/13/crti.o
[clang] [Driver] Simply some gcc search logic (PR #72558)
https://github.com/tstellar closed https://github.com/llvm/llvm-project/pull/72558 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Driver] Simply some gcc search logic (PR #72558)
https://github.com/tstellar updated
https://github.com/llvm/llvm-project/pull/72558
>From 3a0896141cf11c604f28326b3a6eee3762b4f79d Mon Sep 17 00:00:00 2001
From: Tom Stellard
Date: Thu, 16 Nov 2023 05:54:29 +
Subject: [PATCH 1/2] [Driver] Simply some gcc search logic
---
clang/lib/Driver/ToolChains/Gnu.cpp | 18 +++---
clang/lib/Driver/ToolChains/Gnu.h | 1 -
2 files changed, 7 insertions(+), 12 deletions(-)
diff --git a/clang/lib/Driver/ToolChains/Gnu.cpp
b/clang/lib/Driver/ToolChains/Gnu.cpp
index 19dff4ec4d45e08..d92c0f7f8984758 100644
--- a/clang/lib/Driver/ToolChains/Gnu.cpp
+++ b/clang/lib/Driver/ToolChains/Gnu.cpp
@@ -2117,14 +2117,17 @@ void Generic_GCC::GCCInstallationDetector::init(
// The compatible GCC triples for this particular architecture.
SmallVector CandidateTripleAliases;
SmallVector CandidateBiarchTripleAliases;
+ // Add some triples that we want to check first.
+ CandidateTripleAliases.push_back(TargetTriple.str());
+ std::string TripleNoVendor = TargetTriple.getArchName().str() + "-" +
+ TargetTriple.getOSAndEnvironmentName().str();
+ if (TargetTriple.getVendor() == llvm::Triple::UnknownVendor) {
+CandidateTripleAliases.push_back(TripleNoVendor);
+ }
CollectLibDirsAndTriples(TargetTriple, BiarchVariantTriple, CandidateLibDirs,
CandidateTripleAliases, CandidateBiarchLibDirs,
CandidateBiarchTripleAliases);
- TripleNoVendor = TargetTriple.getArchName().str() + "-" +
- TargetTriple.getOSAndEnvironmentName().str();
- StringRef TripleNoVendorRef(TripleNoVendor);
-
// If --gcc-install-dir= is specified, skip filesystem detection.
if (const Arg *A =
Args.getLastArg(clang::driver::options::OPT_gcc_install_dir_EQ);
@@ -2204,13 +2207,6 @@ void Generic_GCC::GCCInstallationDetector::init(
// Maybe filter out /gcc and /gcc-cross.
bool GCCDirExists = VFS.exists(LibDir + "/gcc");
bool GCCCrossDirExists = VFS.exists(LibDir + "/gcc-cross");
- // Try to match the exact target triple first.
- ScanLibDirForGCCTriple(TargetTriple, Args, LibDir, TargetTriple.str(),
- false, GCCDirExists, GCCCrossDirExists);
- // If vendor is unknown, let's try triple without vendor.
- if (TargetTriple.getVendor() == llvm::Triple::UnknownVendor)
-ScanLibDirForGCCTriple(TargetTriple, Args, LibDir, TripleNoVendorRef,
- false, GCCDirExists, GCCCrossDirExists);
for (StringRef Candidate : CandidateTripleAliases)
ScanLibDirForGCCTriple(TargetTriple, Args, LibDir, Candidate, false,
GCCDirExists, GCCCrossDirExists);
diff --git a/clang/lib/Driver/ToolChains/Gnu.h
b/clang/lib/Driver/ToolChains/Gnu.h
index dcfc6307cac79e5..0b664a182d75e1c 100644
--- a/clang/lib/Driver/ToolChains/Gnu.h
+++ b/clang/lib/Driver/ToolChains/Gnu.h
@@ -249,7 +249,6 @@ class LLVM_LIBRARY_VISIBILITY Generic_GCC : public
ToolChain {
void print(raw_ostream ) const;
private:
-std::string TripleNoVendor;
static void
CollectLibDirsAndTriples(const llvm::Triple ,
const llvm::Triple ,
>From 994b7846d73b05ff8f5a41c56535e43e72f90220 Mon Sep 17 00:00:00 2001
From: Tom Stellard
Date: Wed, 22 Nov 2023 00:18:57 +
Subject: [PATCH 2/2] Fix formatting
---
clang/lib/Driver/ToolChains/Gnu.cpp | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/clang/lib/Driver/ToolChains/Gnu.cpp
b/clang/lib/Driver/ToolChains/Gnu.cpp
index d92c0f7f8984758..0ea2df2ca8d87e2 100644
--- a/clang/lib/Driver/ToolChains/Gnu.cpp
+++ b/clang/lib/Driver/ToolChains/Gnu.cpp
@@ -2121,9 +2121,9 @@ void Generic_GCC::GCCInstallationDetector::init(
CandidateTripleAliases.push_back(TargetTriple.str());
std::string TripleNoVendor = TargetTriple.getArchName().str() + "-" +
TargetTriple.getOSAndEnvironmentName().str();
- if (TargetTriple.getVendor() == llvm::Triple::UnknownVendor) {
+ if (TargetTriple.getVendor() == llvm::Triple::UnknownVendor)
CandidateTripleAliases.push_back(TripleNoVendor);
- }
+
CollectLibDirsAndTriples(TargetTriple, BiarchVariantTriple, CandidateLibDirs,
CandidateTripleAliases, CandidateBiarchLibDirs,
CandidateBiarchTripleAliases);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
