GeezerVison is showing github.com — Add a `Py_JIT_ENABLED` variable to `pyconfig.h` · Issue #126204 · python/cpython
Add a Py_JIT_ENABLED variable to pyconfig.h #126204DescriptionFeature or enhancement
Proposal:
On Windows(more exactly on all non-configure builds), currently there is no way to determine if CPython is built with a JIT.
This is a blocker for #126166.
I'm propose adding a variable Py_JIT (maybe this is not a great name..) to pyconfig.h.
Has this already been discussed elsewhere?
No response given
Links to previous discussion of this feature:
No response
Linked PRs
ActivityEclips4 commented on Oct 30, 2024 Possible values for Py_JIT:
- 0 - CPython was built without
JIT
- 1- CPython was built with
JIT
- interpreter - CPython was built without
JIT but with enabled tier 2 interpreter.
ZeroIntensity commented on Oct 30, 2024 Bikeshedding: Py_HAS_JIT might be more clear. I don't want Py_JIT to get confused with the PYTHON_JIT env var :) Eclips4 commented on Oct 30, 2024
Bikeshedding: Py_HAS_JIT might be more clear. I don't want Py_JIT to get confused with the PYTHON_JIT env var :)
After taking a look at pyconfig.h, I think name Py_JIT_ENABLED is more appropriate Reacted by Peter Bierma, RUANG (James Roy) and Erlend E. Aasland changed the title [-]Add a `Py_JIT` variable to `pyconfig.h`[/-] [+]Add a `Py_JIT_ENABLED` variable to `pyconfig.h`[/+] on Oct 30, 2024zooba commented on Oct 31, 2024 If it's at all possible to do this with a sysconfig variable that's pulled from something compiled into the _sysconfig module, that would be better. Messing with pyconfig.h is complicated, and we already regret trying to do it for freethreading (and I can't wait for that change to be removed/committed).
It does mean that build tools need to learn to check for it and set the variable, if it matters that extension modules have the variable set (which I'd have thought it doesn't). If it doesn't affect how extension modules should be compiled, then it shouldn't be in pyconfig.h on Windows. Eclips4 commented on Nov 1, 2024
It does mean that build tools need to learn to check for it and set the variable, if it matters that extension modules have the variable set (which I'd have thought it doesn't). If it doesn't affect how extension modules should be compiled, then it shouldn't be in pyconfig.h on Windows.
Agreed. And yes, there is a way to change only _sysconfig which works fine for both types of builds (configure-based and Windows). After reading your message, I think we don't need to change pyconfig.h even for configure-based builds since it doesn't affect how extension modules should be compiled. What do you think? brandtbucher commented on Nov 1, 2024 I'd much rather add sys utilities for this. pyconfig.h is a home for stuff that extensions need at compile-time, not a home for stuff that Python code needs at runtime.
I propose sys._jit_enabled(), returning either True or False. On JIT builds, where the JIT is actually enabled at runtime, it returns True. If the JIT is built but not enabled, it returns False.
On non-jit builds, including the tier-two interpreter, it always returns False. That seems the most useful, I think? Reacted by Kirill Podoprigora zooba commented on Nov 4, 2024 I'm inclined to agree that sys might be the best place, but would propose:
- JIT active -
sys._jit_enabled() -> True
- JIT not active -
sys._jit_enabled() -> False
- JIT not built -
sys._jit_enabled -> AttributeError
There doesn't seem to be any need for the function at all if it's absent, and it's not the first time we've built in an optional private attribute here. Given it's a compile-time build option already it's just as easy to make the whole function disappear as to give it a different implementation. Reacted by alm and Kirill Podoprigora Eclips4 commented on Jan 30, 2025
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|