This is an archive of the discontinued LLVM Phabricator instance.

Add build for Windows on Arm in packaging script
AbandonedPublic

Authored by pbo-linaro on Oct 27 2022, 10:14 PM.

Diff Detail

Event Timeline

pbo-linaro created this revision.Oct 27 2022, 10:14 PM
Herald added a project: Restricted Project. · View Herald Transcript
pbo-linaro requested review of this revision.Oct 27 2022, 10:14 PM
Herald added a project: Restricted Project. · View Herald TranscriptOct 27 2022, 10:14 PM
pbo-linaro edited reviewers, added: omjavaid; removed: sscalpone.Oct 27 2022, 10:15 PM
omjavaid added inline comments.Nov 2 2022, 2:16 AM
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.

pbo-linaro added inline comments.Nov 2 2022, 2:33 AM
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.
(build32 and build64 are already duplicated).

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!
It should be enough to configure CPACK_SYSTEM_NAME to woa64 for obtaining this result. I'll give it a try.
https://cmake.org/cmake/help/latest/module/CPack.html#variable:CPACK_PACKAGE_FILE_NAME

389

I can remove this step (just did the same than original tcwg script).

omjavaid added inline comments.Nov 2 2022, 2:49 AM
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.

pbo-linaro added inline comments.Nov 2 2022, 2:56 AM
llvm/utils/release/build_llvm_release.bat
298

Ok, in this case I'll refactor this between the 3 arch.

pbo-linaro updated this revision to Diff 472869.Nov 3 2022, 1:27 AM

Factor steps with other architectures.

pbo-linaro marked 5 inline comments as done.Nov 3 2022, 1:28 AM

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.

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.

I'll implement this in another patch, that's a great idea.

@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

pbo-linaro added a comment.EditedJan 6 2023, 2:53 AM

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).

pbo-linaro abandoned this revision.Jan 31 2023, 3:49 AM

Closed in favor of a new patch that will upstreamed soon.