[windows][toolchain] Build sanitizers and builtins standalone for all SDKs #78861
Conversation
weliveindetail
requested review from
compnerd,
slavapestov,
rjmccall and
artemcm
as code owners
| function Build-Sanitizers([Platform]$Platform, $Arch) { | ||
| $BareTarget = $Arch.LLVMTarget.Replace("$AndroidAPILevel", "") | ||
| $LLVMDir = "$(Get-TargetProjectBinaryCache $Arch LLVM)\lib\cmake\llvm" | ||
| $InstallTo = "$($HostArch.ToolchainInstallRoot)\usr\lib\clang\19" |
There was a problem hiding this comment.
Can we keep it like that? I can probably get it from running stage-1 Clang, or lit
There was a problem hiding this comment.
I think that we should extract this from the build, the resource dir changes on each rebranch, and this will complicate things.
| COMPILER_RT_BUILD_ORC = "NO"; | ||
| COMPILER_RT_BUILD_XRAY = "NO"; | ||
| COMPILER_RT_BUILD_PROFILE = "YES"; | ||
| COMPILER_RT_BUILD_SANITIZERS = "YES"; |
There was a problem hiding this comment.
I could put this into a CMake cache file, but it won't get much simpler
There was a problem hiding this comment.
Yeah, I can see why it would not simplify much, but, it does make it more obvious that this is static configuration and not logic when you need a last second change to the build.
There was a problem hiding this comment.
OTOH the structure in https://github.com/swiftlang/swift/tree/main/cmake/caches forces us to add 7 new files. And they all have identical content. (Unless we outsource CMAKE_SYSTEM_NAME, but it won't make that much of a difference.) I guess it should be: LLVM-$Platform-$($Arch.LLVMName).cmake
|
@swift-ci Please test Windows |
| @@ -1606,6 +1608,52 @@ function Build-LLVM([Platform]$Platform, $Arch) { | |||
| } | |||
| } | |||
|
|
|||
| function Build-Sanitizers([Platform]$Platform, $Arch) { | |||
| $BareTarget = $Arch.LLVMTarget.Replace("$AndroidAPILevel", "") | |||
There was a problem hiding this comment.
I believe that @andrurogerz is working on creating a ModuleTriple parameter in the architecture definition to help with this.
There was a problem hiding this comment.
Oh good, yeah this difference is nifty. The unified build used to pass it via LLVM_RUNTIMES_TARGET
here, but in the standalone build CMake reports it as unused. Will drop it here.
| @@ -1606,6 +1608,52 @@ function Build-LLVM([Platform]$Platform, $Arch) { | |||
| } | |||
| } | |||
|
|
|||
| function Build-Sanitizers([Platform]$Platform, $Arch) { | |||
| $BareTarget = $Arch.LLVMTarget.Replace("$AndroidAPILevel", "") | |||
| $LLVMDir = "$(Get-TargetProjectBinaryCache $Arch LLVM)\lib\cmake\llvm" | |||
There was a problem hiding this comment.
Should this be target? What happens if we don't have a target build of LLVM? (e.g. Android)
There was a problem hiding this comment.
This came up as a warning during configuration. In many cases standalone builds reach out to LLVM for configuration details or test dependencies. That should work because we do configure LLVM for Android targets. Let me double-check that.
| function Build-Sanitizers([Platform]$Platform, $Arch) { | ||
| $BareTarget = $Arch.LLVMTarget.Replace("$AndroidAPILevel", "") | ||
| $LLVMDir = "$(Get-TargetProjectBinaryCache $Arch LLVM)\lib\cmake\llvm" | ||
| $InstallTo = "$($HostArch.ToolchainInstallRoot)\usr\lib\clang\19" |
There was a problem hiding this comment.
I think that we should extract this from the build, the resource dir changes on each rebranch, and this will complicate things.
| -UseBuiltCompilers C,CXX ` | ||
| -BuildTargets "install-compiler-rt" ` | ||
| -Defines (@{ | ||
| CMAKE_MT = "mt"; |
| -UseBuiltCompilers C,CXX ` | ||
| -BuildTargets "install-compiler-rt" ` | ||
| -Defines (@{ | ||
| CMAKE_MT = "mt"; |
| COMPILER_RT_BUILD_ORC = "NO"; | ||
| COMPILER_RT_BUILD_XRAY = "NO"; | ||
| COMPILER_RT_BUILD_PROFILE = "YES"; | ||
| COMPILER_RT_BUILD_SANITIZERS = "YES"; |
There was a problem hiding this comment.
Yeah, I can see why it would not simplify much, but, it does make it more obvious that this is static configuration and not logic when you need a last second change to the build.
Unified build of compiler-rt together with LLVM failed for the Android SDKs. It got too complicated to redirect the way LLVM would configure the nested build-trees. Standalone builds slightly increase build time, but they turned out much simpler and we end up with less duplication of definitions.