Skip to content
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

gh-130039: Tailcall for windows builds #130040

Open
wants to merge 17 commits into
base: main
Choose a base branch
from

Conversation

Fidget-Spinner
Copy link
Member

@Fidget-Spinner Fidget-Spinner commented Feb 12, 2025

@Fidget-Spinner
Copy link
Member Author

@mdboom I'm baffled by the error in the CI. By any chance do you know how to fix it? https://github.com/python/cpython/actions/runs/13287244377/job/37098802007?pr=130040

@mdboom
Copy link
Contributor

mdboom commented Feb 12, 2025

@mdboom I'm baffled by the error in the CI. By any chance do you know how to fix it? https://github.com/python/cpython/actions/runs/13287244377/job/37098802007?pr=130040

I can try poking at this locally a bit later today, but my first guess is that it's because the equals sign is getting swallowed here:

/p:PlatformToolset clangcl

...so clangcl is just seen as another project name.

I don't really understand the quoting rules for PowerShell -- maybe "/p:PlatformToolset\=clangcl" is needed?

I think I ran into this same problem in bench-runner, and I ultimately gave up and used cmd rather than PowerShell, which you can do by putting shell: cmd above the run: ... in the yml file. See here for how I solved a similar problem in bench_runner.

@Fidget-Spinner
Copy link
Member Author

That makes sense. Thanks. Applied the change to use cmd instead!

@Fidget-Spinner
Copy link
Member Author

@chris-eibl I guess we're blocked on getting patches to make clang-cl build CPython. Currently there's a few build errors which I assume you patched out on your branch? Do you mind upstreaming those patches? I can review them.

@Fidget-Spinner
Copy link
Member Author

Nevermind, I will try to patch them into this PR as well, so that we can do an integration test.

@chris-eibl
Copy link
Contributor

chris-eibl commented Feb 12, 2025

I don't really understand the quoting rules for PowerShell -- maybe "/p:PlatformToolset\=clangcl" is needed?

Yeah, see this part of build.bat -h:

If the argument contains an '=', the
entire argument must be quoted (e.g. `build.bat "/p:PlatformToolset=v141"`).

Had a quick look at the PR and everything looks fine to me.

The build log of your latest commit 7f91920 shows

  Performing Custom Build Tools
   Assembling: D:\a\cpython\cpython\externals\mpdecimal-4.0.0\libmpdec\vcdiv64.asm
  error: symbol 'AsyncioDebug' is already defined

I have never seen that error before.

For sure not during assembling, must come out of _asynciomodule.c:

GENERATE_DEBUG_SECTION(AsyncioDebug, Py_AsyncioModuleDebugOffsets AsyncioDebug)

That's the only occurence I've found.

Ah - you've found it yourself while I was typing :)

Interestingly: I cannot reproduce locally for the failing commit 7f91920 using:

build.bat --tail-call-interp -p x64 -c Release "/p:PlatformToolset=clangcl" "/p:PreferredToolArchitecture=x64"

with Visual Studio 2022 17.13.0 Preview 5.0, which ships with cl.exe 19.43.34808 and clang 19.1.1.

Let's see whether your latest commit fixes CI - looks promising :)

@mdboom
Copy link
Contributor

mdboom commented Feb 12, 2025

Yeah, see this part of build.bat -h:

If the argument contains an '=', the
entire argument must be quoted (e.g. `build.bat "/p:PlatformToolset=v141"`).

I'm pretty sure this advice assumes using cmd, not PowerShell (which is the default on Github Actions). Overriding the shell used on Github Actions seems to be the easy solution. The harder solution is figuring out PowerShell's escaping rules...

@Fidget-Spinner
Copy link
Member Author

with Visual Studio 2022 17.13.0 Preview 5.0, which ships with cl.exe 19.43.34808 and clang 19.1.1.

Let's see whether your latest commit fixes CI - looks promising :)

That didn't fix it :(.

@chris-eibl
Copy link
Contributor

Ups - still the same error - very weird. No idea atm - sorry ...

@chris-eibl
Copy link
Contributor

chris-eibl commented Feb 12, 2025

Unfortunately I cannot reproduce locally. Have a different clang version, though. Did also use clang 19.1.6 a lot.

Will fire up a build for this commit ...

Update:
Commit 7f91920 builds for me with clang 19.1.6, too:

build.bat --tail-call-interp -p x64 -c Release "/p:PlatformToolset=clangcl" "/p:LLVMToolsVersion=19.1.6" "/p:LLVMInstallDir=clang+llvm-19.1.6-x86_64-pc-windows-msvc"

@Fidget-Spinner
Copy link
Member Author

Ah.. I think I forgot to add parentheses :) my bad

@Fidget-Spinner
Copy link
Member Author

Nevermind, that didn't fix it. Now that I look at the macros closer, it shouldn't fix it either.

@chris-eibl
Copy link
Contributor

Really strange why that happens on CI. Cannot reproduce with clang 19.1.1 and 19.1.6.
The CI seems to use 19.1.5 - but hard to believe this is the culprit.

Those macros have been touched recently #129223.
Yet, I never had an issue with clang-cl so far (and still have not).

@Fidget-Spinner
Copy link
Member Author

Fixed it on CI!

choco install llvm --allow-downgrade --no-progress --version ${{ matrix.llvm }}.1.0
./PCbuild/build.bat --tail-call-interp -d -p ${{ matrix.architecture }}
choco install llvm --allow-downgrade --no-progress --version ${{ matrix.llvm }}.1.5
./PCbuild/build.bat --tail-call-interp -d -p ${{ matrix.architecture }} "/p:PlatformToolset=clangcl" "/p:LLVMToolsVersion=19.1.5" "/p:LLVMInstallDir=C:\Program Files\LLVM"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might be convenient to add --clang as a build.bat option, though you'd still need the quoting to get the other variables in.

Also, FWIW, unless you're explicitly trying to override other settings, you can set these variables as environment variables instead. The MSBuild files can override those if it isn't authored properly, but at least PlatformToolset is correct, and I expect the other two will be too.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, I was thinking of using the default clang that comes with VS. The latest VS comes with Clang 19, so it's perfect for this. However, I don't know if the CI runners updated to use the latest VS yet, and I don't want a situation where sometimes we break on older VS and sometimes we don't. So for now, I'll let users manually specify, and maybe in a year or so we can revisit adding a --clang option.

@Fidget-Spinner Fidget-Spinner requested a review from zooba February 13, 2025 15:37
@Fidget-Spinner
Copy link
Member Author

@zooba gentle ping for a review please. Thanks again for reviewing that other PR on getting PGO working on clang-cl. This should be relatively tame in comparison :).

@@ -23,7 +23,7 @@ extern "C" {
declaration \
_GENERATE_DEBUG_SECTION_LINUX(name)

#if defined(MS_WINDOWS)
#if defined(MS_WINDOWS) && !defined(__clang__)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this need an alternate definition for Windows + clang?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, below there's a default that it uses is we're not one of the supported platforms. And that default works for Clang Windows.

@@ -2,12 +2,14 @@ name: Tail calling interpreter
on:
pull_request:
paths:
- '.github/workflows/tail-call.yml'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This feels wrong to me, but if it's needed, then sure. Hopefully someone else can sign off on this part of the change.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is fine: when changing this file, it's good to run it as well to make sure we didn't break it -- which is rather too easy with YAML.


(And let's strip the trailing spaces.)

Suggested change
- '.github/workflows/tail-call.yml'
- '.github/workflows/tail-call.yml'

(We should add yaml to this list, feel free to include it in the PR if you like:)

types_or: [c, inc, python, rst]

We can't specify the minor version as the apt script doesn't recognize it.
@zooba
Copy link
Member

zooba commented Mar 10, 2025

Looks fine to me.

I hope we can justify (one day) taking options out of build.bat without deprecation periods and warnings. I think we probably can. In any case, this PR isn't the cause of sprawling options, so no harm in merging it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants