Add a Py_JIT_ENABLED variable to pyconfig.h

[Eclips4]

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

Linked PRs

• gh-126204: Add a sys._jit_enabled helper #126247

[Eclips4]

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]

Bikeshedding: Py_HAS_JIT might be more clear. I don't want Py_JIT to get confused with the PYTHON_JIT env var :)

[Eclips4]

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

[zooba]

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]

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]

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?

[zooba]

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.