GH-141362: Make get_externals handle fetching platform-specific release artifacts

[savannahostrowski]

This PR adds support for downloading platform-specific LLVM binaries (AMD64, ARM64) instead of using a single binary with emulation (see https://github.com/python/cpython-bin-deps/releases/tag/llvm-21.1.4.0 for release artifacts). Since this won't naturally trigger jit.yml, you can see a successful run here, including print statements to show that we are in fact downloading the correct binary 😄.

• Issue: Make get_externals handle fetching platform-specific release artifacts #141362

[diegorusso]

I have a comment not related to this PR, but I just want to have your input @zooba

don't think we care about building on true 32-bit OS anymore.

This is fair but what about running on a true 32-bit OS? I see i686-pc-windows-msvc is "still" in tier-1. It made sense 10-15 years ago, but what about today? Is it still so popular/used out there?
The reason I'm asking is because failures on this platform will be hard to reproduce for the lack of HW/SW as it won't be accessible to everyone.
My suggestion is to demote it to tier-2, similarly to what we have done with x86_64-apple-darwin.

I'm more than happy to move the conversation on DPO if you think we need more discussion.

[chris-eibl]

This is fair but what about running on a true 32-bit OS?

Yeah, especially since the JIT is having a hard time on x86 due to spilling (because there are so few registers).

@brandtbucher 's PR for preserve_none x86 llvm/llvm-project#150106 will help, but it seems stalled.

Tailcalling doesn't work on Windows x86 (upcoming #139962), because MSVC doesn't support it for x86 (at least not in VS 2026, no idea whether this will ever be supported).

There was a long discussion in https://discuss.python.org/t/consider-downgrading-windows-32-bit-from-tier-1-to-tier-2-or-tier-3-in-python-3-13/33719, but the outcome was to keep Windows x86 in tier-1.

And the 32bit installer link was ranked after the 64bit installer on python.org so unaware people less likely choose it over 64bit 🚀

The reason I'm asking is because failures on this platform will be hard to reproduce for the lack of HW/SW as it won't be accessible to everyone.

Even though Windows 10 is EOL (which was the last one where you could choose between 32bit/64bit when installing) and Windows 11 is 64bit only during installing, there is the compatibility layer to run 32bit software in 64bit Windows.
This compatibility will most probably be kept by MS for another decade (or forever), and so we can still test it. And I think it's these users we care about: having legacy software that is not yet ported to 64bit and embeds Python or imports a 32bit Python DLL.

My suggestion is to demote it to tier-2, similarly to what we have done with x86_64-apple-darwin.

One outcome in the above discussion was, that ¹

the cost of supporting 32-bit Windows specifically is probably not very high for CPython

This might no longer be true for the JIT?

Footnotes

1. https://discuss.python.org/t/consider-downgrading-windows-32-bit-from-tier-1-to-tier-2-or-tier-3-in-python-3-13/33719/23 ↩

[diegorusso]

Thanks Savannah for your patience on getting this implemented. I think it behaves as it should be and LGTM. I prefer though if you have the blessing of some Windows expert :)

[chris-eibl]

LGTM.

Maybe we can somewhere document that get_external.py does react on the environment variable PreferredToolArchitecture to override the llvm tool architecture that is used to build the stencils? E.g. in Tools/README.md?

Sorry to be picky. Final decision is anyway up to Steve ...

[chris-eibl]

Thanks Savannah!

[savannahostrowski]

Thanks for reviewing @chris-eibl! Appreciate it!

[savannahostrowski]

Given that this has gotten a stamp from Diego and Chris (and I know Steve is out for quite some time), I will merge this. I am happy to revisit any and all parts if there is additional feedback! Thank you all for the reviews!