Repository navigation
Add a Py_JIT_ENABLED variable to pyconfig.h #126204
Description
Activity
Possible values for
Py_JIT:- 0 - CPython was built without
JIT - 1- CPython was built with
JIT - interpreter - CPython was built without
JITbut with enabled tier 2 interpreter.
- 0 - CPython was built without
Bikeshedding:
Py_HAS_JITmight be more clear. I don't wantPy_JITto get confused with thePYTHON_JITenv var :)Bikeshedding:
Py_HAS_JITmight be more clear. I don't wantPy_JITto get confused with thePYTHON_JITenv var :)After taking a look at
pyconfig.h, I think namePy_JIT_ENABLEDis more appropriateReacted 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, 2024 If it's at all possible to do this with a
sysconfigvariable that's pulled from something compiled into the_sysconfigmodule, 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.
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
_sysconfigwhich works fine for both types of builds (configure-based and Windows). After reading your message, I think we don't need to changepyconfig.heven for configure-based builds since it doesn't affect how extension modules should be compiled. What do you think?I'd much rather add
sysutilities for this.pyconfig.his 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 eitherTrueorFalse. On JIT builds, where the JIT is actually enabled at runtime, it returnsTrue. If the JIT is built but not enabled, it returnsFalse.On non-jit builds, including the tier-two interpreter, it always returns
False. That seems the most useful, I think?Reacted by Kirill PodoprigoraI'm inclined to agree that
sysmight 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- JIT active -
Feature 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..) topyconfig.h.Has this already been discussed elsewhere?
No response given
Links to previous discussion of this feature:
No response
Linked PRs
sys._jit_enabledhelper #126247