Repository navigation
Add a Py_JIT_ENABLED variable to pyconfig.h #126204
Description
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..) to pyconfig.h.
Has this already been discussed elsewhere?
No response given
Links to previous discussion of this feature:
No response
Activity
Eclips4 commentedon Oct 30, 2024
Possible values for
Py_JIT:JITJITJITbut with enabled tier 2 interpreter.ZeroIntensity commentedon Oct 30, 2024
Bikeshedding:
Py_HAS_JITmight be more clear. I don't wantPy_JITto get confused with thePYTHON_JITenv var :)Eclips4 commentedon Oct 30, 2024
After taking a look at
pyconfig.h, I think namePy_JIT_ENABLEDis more appropriate[-]Add a `Py_JIT` variable to `pyconfig.h`[/-][+]Add a `Py_JIT_ENABLED` variable to `pyconfig.h`[/+]zooba commentedon Oct 31, 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.
Eclips4 commentedon Nov 1, 2024
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?brandtbucher commentedon Nov 1, 2024
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?zooba commentedon Nov 4, 2024
I'm inclined to agree that
sysmight be the best place, but would propose:sys._jit_enabled() -> Truesys._jit_enabled() -> Falsesys._jit_enabled -> AttributeErrorThere 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.
Eclips4 commentedon Jan 30, 2025
Done in #129194.