Details
- Reviewers
omjavaid sscalpone maxim-kuvyrkov
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/utils/release/build_llvm_release.bat | ||
---|---|---|
281 | There seems to a lot of similarities overall can we combine build64 and do_build_arm64. | |
298 | We are doing libxmlbuild above for x64 as well. This is duplicating the same code. | |
385 | cant we produce woa64 package that we dont have to rename it here. | |
389 | zip file seems redundant. |
llvm/utils/release/build_llvm_release.bat | ||
---|---|---|
298 | I agree, but I'd prefer to factor all this in another patch if that's fine for you. The goal is to upstream faster arm64 build (instead of doing a refactor patch before), and then do a cleanup where people can argue :) | |
385 | Good point! | |
389 | I can remove this step (just did the same than original tcwg script). |
llvm/utils/release/build_llvm_release.bat | ||
---|---|---|
298 | We already have a working copy of this script in Linaro toolchain repositories. There is no urgency to have the same build script available in LLVM upstream mono repo. We still have 8 - 12 weeks until next LLVM release is due so we should target for a cleaned up script with minimum or no duplication. |
llvm/utils/release/build_llvm_release.bat | ||
---|---|---|
298 | Ok, in this case I'll refactor this between the 3 arch. |
All three architectures now share environment setup and libxml build, so there is no more code duplication.
Waiting for https://reviews.llvm.org/D138023 to be merged.
Once done, workaround for "builtin" required to build flang can be removed from this patch.
This looks like a good time to merge this script however some changes are needed:
Stage 0 projects for all configurations should be -DLLVM_ENABLE_PROJECTS="clang;clang-tools-extra;lld;compiler-rt". We are essentially just building a new version of clang for making the final release build on stage 1 using our newly built compiler. LLDB or OpenMP is not needed at this stage and can be excluded from the build.
Stage 1 projects for all configurations should be -DLLVM_ENABLE_PROJECTS="clang;clang-tools-extra;lld;compiler-rt;lldb;openmp;flang". x86/x64 might not compile flang and Arm64 might not compile openmp. We leave it for the release manager to decide that and make a local change if that is the case.
Stage 0 and Stage 1 Arm64 specific flags are given below (everything else should look similar to x64 and both configurations can be merged):
-DCOMPILER_RT_BUILD_SANITIZERS=OFF ^
-DCOMPILER_RT_BUILD_PROFILE=OFF ^
We do not require anything else specific to Arm64 execept for the flags given above, which allows us to use a single do_build64 for both x64 and arm64 after making some minor adjustments to current implementation. Moreover all testsuites should be enabled for both x64 and arm64. We leave it to the release manager to disable certain testsuite for example ninja check-sanitizer will be have to be commented for arm64 build. We can leave a comment about this above the line starting ::ninja check-sanitizer.
Also it would be great if we allow user to choose between cl and clang-cl for the stage 0 build using a command line option and set CMAKE_C_COMPILER and CMAKE_CXX_COMPILER accordingly.
@omjavaid After testing with LLVM main branch, removing the flags (and especially the *LINKER_FLAGS=$builtins) results in a link failure during stage 1:
FAILED: tools/flang/unittests/Decimal/quick-sanity-test.test.exe cmd.exe /C "cd . && C:\wenv\arm64\cmake\bin\cmake.exe -E vs_link_exe --intdir=tools\flang\unittests\Decimal\CMakeFiles\quick-sanity-test.test.dir --rc=C:\PROGRA~2\WI3CF2~1\10\bin\100226~1.0\x64\rc.exe --mt=C:\PROGRA~2\WI3CF2~1\10\bin\100226~1.0\x64\mt.exe --manifests -- C:\work\recipes\llvm-release\llvm_package_main\build_arm64_stage0\bin\lld-link.exe /nologo tools\flang\unittests\Decimal\CMakeFiles\quick-sanity-test.test.dir\quick-sanity-test.cpp.obj /out:tools\flang\unittests\Decimal\quick-sanity-test.test.exe /implib:lib\quick-sanity-test.test.lib /pdb:tools\flang\unittests\Decimal\quick-sanity-test.test.pdb /version:0.0 /machine:ARM64 /STACK:10000000 /INCREMENTAL:NO /subsystem:console lib\LLVMSupport.lib lib\FortranDecimal.lib psapi.lib shell32.lib ole32.lib uuid.lib advapi32.lib delayimp.lib -delayload:shell32.dll -delayload:ole32.dll lib\LLVMDemangle.lib kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib && cd ." LINK: command "C:\work\recipes\llvm-release\llvm_package_main\build_arm64_stage0\bin\lld-link.exe /nologo tools\flang\unittests\Decimal\CMakeFiles\quick-sanity-test.test.dir\quick-sanity-test.cpp.obj /out:tools\flang\unittests\Decimal\quick-sanity-test.test.exe /implib:lib\quick-sanity-test.test.lib /pdb:tools\flang\unittests\Decimal\quick-sanity-test.test.pdb /version:0.0 /machine:ARM64 /STACK:10000000 /INCREMENTAL:NO /subsystem:console lib\LLVMSupport.lib lib\FortranDecimal.lib psapi.lib shell32.lib ole32.lib uuid.lib advapi32.lib delayimp.lib -delayload:shell32.dll -delayload:ole32.dll lib\LLVMDemangle.lib kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib /MANIFEST /MANIFESTFILE:tools\flang\unittests\Decimal\quick-sanity-test.test.exe.manifest" failed (exit code 1) with the following output: lld-link: error: undefined symbol: __udivti3
Leaving the builtins flag make the stage1 succeed.
Could you investigate this, and see if it compiles cleanly on your side?
Thanks
There must be some issue with your configuration possible not testing the top of tree main branch as 15.0.6 may not have the patches for the build to succeed. Please follow the instructions on link provided below to setup your test machine:
https://linaro.atlassian.net/wiki/spaces/TCWGPUB/pages/28809266294/How+to+setup+LLVM+buildbots+for+Windows+11+on+Arm
There are successful LLVM (including flang) builds running on LLVM buildbots. Unfortunately there are still on my private tests master (User Name: Omair, Password: Password)
so you can find a quick bot reference build here:
http://139.178.84.207:49161/#/builders/181/builds/331
and two stage reference build here:
http://139.178.84.207:49161/#/builders/120/builds/34
Note: I ll be out of office till Tuesday but will be replying email intermittently
I explicitely tested with main (from 5th of January), and not with 15.0.6.
Considering it works with keeping the builtins flag, I hardly see how the machine configuration could be bad.
Would that be possible for you to update the patch and test in on your configuration?
It's pretty easy to do versus configuring a whole machine from scratch for me.
Thanks
After discussion, we'll explicitely wait for 16.0.0-rc1 tag, so the script can be directly used with this reference (not the case with main branch).
There seems to a lot of similarities overall can we combine build64 and do_build_arm64.