-
Notifications
You must be signed in to change notification settings - Fork 29.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
build: enable Clang-cl Windows builds #35433
Conversation
# else | ||
*pCPU = IMAGE_FILE_MACHINE_UNKNOWN; | ||
*pCPU = IMAGE_FILE_MACHINE_AMD64; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is for #34201
With all the above hacks, I am blocked on this error:
Related warning in the build output:
node/deps/v8/src/objects/objects.h Lines 815 to 833 in 4a6005c
node/deps/v8/src/objects/string.h Lines 821 to 836 in 4a6005c
|
/cc @nodejs/v8 |
Another tricky thing is that we can't even test this on github action due to space limit https://github.com/nodejs/node/pull/35433/checks?check_run_id=1189469828 |
Regarding the disk space issue: the D:\ drive on Windows VMs apparently has 14GB available - this is also described in the official docs. A workaround is to move things to the C:\ drive which has 80GB+ as described in actions/runner-images#1341 (comment) |
@targos Can you rebase this, so we can working on new V8 ? |
I investigate a little bit, looks like not an easy thing to do: actions/checkout#197. Also, below won't work either on windows CI on github action.
Not sure why they default to drive D with such a limited disk space. |
Rebased on #35700 |
I don't know if CI has clang-cl. Let's try: https://ci.nodejs.org/job/node-test-commit-windows-fanned/38888/ Edit: well, it doesn't 😄
|
@nodejs/build-infra Would it be easy to install ClangCL build tools on the Windows machines? |
Not sure this will help: https://github.com/appveyor/build-images/blob/27bde614bc60d7ef7a8bc46182f4d7582fa11b56/scripts/Windows/install_vs2019.ps1#L192. |
So I tried to build it on my local machine. There's one warning that is very noisy (I think it's printed for every V8 source file:
Then it fails with 3 errors (related warnings included):
|
Looks like all related to inline function on windows platform. |
This comment has been minimized.
This comment has been minimized.
Now stucks with
Maybe related: https://developercommunity.visualstudio.com/content/problem/1110835/clangcl-ltcg-is-passed-to-llvm-lib.html This occurred when I update my visual studio to latest. I also get some ideas to patch V8 to make the windows build works. |
Just for the record, Visual Studio 16.8 was released yesterday and has the following mentioned in its release notes:
Thought I'd mention it here as it might help for this PR. I have a Surface Pro X based on the arm64 architecture, let me know if you'd like me to test something 👍 |
Just tried to build using @gengjiawen Does it make any difference if you update to Visual Studio 16.8, which was released yesterday? |
I forget to remove '/P'. I should try my build now.
Have you tried the official arm64 build for windows. Will it run ? (I have no device to test it) |
Yes (see nodejs/build#2450 (comment)), and it's blazing fast 🚀 I use it on a daily basis and to work on things like an arm64 build for GitHub Desktop: desktop/desktop#9691 |
This is more likely a bug from what I test (refactor the inline implementation). Not sure this need to reported to clang team or msvc team. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This feature interests me. Looking at the code, this looks like a PoC, which is completely fine for this stage, but I was just wondering what you see as the end result here @targos?
The way I see it, clang and MSVC would both have to be supported in parallel for some time, before potentially moving to Clang completely. In that time, we'd need a way to choose either of them, eg. vcbuild.bat
would still use MSVC, while vcbuild.bat clang
would use clang.
Luckily we could leverage __clang__
to have separate code for the 2 compilers, but we'd probably need either to push some deps
changes upstream, or leave them as floating patches. Overall, it would be good to know the scope of changes and affected dependencies once PoC is done so productization can be planned well.
// TODO: detect ARM64 | ||
# else | ||
*pCPU = IMAGE_FILE_MACHINE_UNKNOWN; | ||
*pCPU = IMAGE_FILE_MACHINE_AMD64; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried an ARM64 build and got an error connected to these changes.
After some investigation, I found that dealing with a TODO: detect ARM64
added here would be tricky. This file is a part of a host project, thus it is always compiled for x64 in our case. Ideally, we'd use _M_ARM64/_M_AMD64
and set different IMAGE_FILE_MACHINE_...
based on that in a target architecture project, but that cannot be used here.
What we can do, is add another option to genccode_host
(genccode.c
) that we'd use for setting the *pCPU
. The issue with it is that the files I'd change in the process are part of the deps
so we'd be making a floating patch on similar to the ones we have on V8, which is not great, but currently I see no other way (although there might be some).
I rebased the branch.
I see the same as you: an optional |
Note that #52714 should help a bit once merged. |
TODO: upstream change to Chromium
1. To avoid many warnings, this PR declares the C and C++ standards separately. 2. This PR extends gyp so that we can build with AVX-512. Nevertheless, getting runtime dispatching with ClangCl through Visual Studio is challenging, so we disable it. It only affects one component of zip, so the effect on runtime performance should be negligible. Note that other dependencies such as simdutf do not need to this build support for runtime dispatching (so you still get AVX2, AVX-512 support in these dependencies).
It seems Windows build is passing? |
Yes, it's been passing for some time. Now what we need to do is go back to all the "hacks" and either convert them to acceptable code or upstream the changes. |
@targos There are three dependencies affected. The zlib changes are not, in my estimation, needed. I have a comment above regarding this. The v8 change should not be needed, indeed Chrome is compiled using ClangCL so it seems unlikely that we would need to patch v8. The remaining one (icu) is mysterious to me... and is the most likely to be strictly needed... |
I ran some limited benchmarks and the results are encouraging, see https://lemire.me/blog/2024/05/02/should-node-js-be-built-with-clangcl-under-windows/ It seems possible that compiling Node.js with ClangCL under Windows would improve the performance. Of course, this requires further validation. |
I opened #52870 to do things correctly and incrementally. |
This is very hacky at the moment. I'm trying to find out what needs to be done to enable it and where.
I'm opening a PR to discuss the changes and seek some help, because it doesn't work yet!
To try it:
.\vcbuild.bat