gh-148284: Block inlining of gigantic functions in ceval.c for clang 22

[Fidget-Spinner]

It seems that on clang-22, the inliner is too aggressive on _PyEval_EvalFrameDefault when on computed goto interpreter. Together with some strange interaction with the stackref buffer, the function requires 40kB of stack space (!!!) versus the usual 1-2kB normally used.

This sets the inline limit to functions of max 512B stack space (1/4th of normal) allowed to be inlined in ceval.c. I checked the dissasembly and the new function uses about 2kB of stack.

• Issue: python -m test -v test_call segfault with clang 22.1.3 build #148284

---

📚 Documentation preview 📚: https://cpython-previews--148334.org.readthedocs.build/

[Fidget-Spinner]

Tested with

RANLIB="/usr/bin/llvm-ranlib-22" LLVM_PROFDATA="/usr/bin/llvm-profdata-22" LLVM_AR="/usr/bin/llvm-ar-22" CC="clang-22" CXX="clang++-22" LDFLAGS="-fuse-ld=lld-22" ./configure --enable-optimizations --with-lto --enable-shared  && make clean && make -j18

test_call fails on main, passes on this branch. Please help me check if you can. Thank you!

[Fidget-Spinner]

So it seems whether the original bug reproduces on main or not is nondeterministic 😨 . However, I still believe this fix is right.

[vstinner]

So it seems whether the original bug reproduces on main or not is nondeterministic 😨 . However, I still believe this fix is right.

I built the Python main branch (without the fix) 3 times in a row from scratch (git clean -fdx): the two first builds didn't reproduce the issue (stack memory per call: 1.2 kB), the 3rd build reproduced the issue (stack memory per call: 33.1 kB).

---

I built the Python main branch on Fedora Rawhide (clang 22.1.3) with:

./configure --enable-optimizations --with-lto --enable-shared CC=clang LD=clang
time make -j14

On the two first builds, LD_LIBRARY_PATH=$PWD ./python -m test -v test_call test passed successfully (expected: test fails). On the 3rd build, the test failed.

Script:

import _testcapi
import functools

def py_call():
    return _testcapi.stack_pointer()

def call():
    return py_call()

start = _testcapi.stack_pointer()
call = functools.partial(call)
top = call()
diff = start - top
print("stack memory per call: %.1f kB" % (diff / 1024))

Output on the first two builds:

stack memory per call: 1.2 kB

Output on the third build:

stack memory per call: 33.1 kB

Note: I installed clang and its dependencies using sudo dnf install clang llvm-ar compiler-rt.

[vstinner]

To get a more reproducible output, I tried using ./python -I -c pass as the "profile task".

Using ./configure --enable-optimizations --with-lto --enable-shared CC=clang LD=clang PROFILE_TASK='-I -c pass', I get a smaller stack memory usage: stack memory per call: 0.8 kB.

I built the Python main branch 3 times with these options and I got the same result each time: test_call pass and stack memory per call: 0.8 kB. I don't reproduce the issue with these options.

[vstinner]

Ok, now testing the fix. I built Python with the fix 5 times in a row and test_call succeeded each time. The fix is reliable!

• Build 1: success (stack memory per call: 1.2 kB)
• Build 2: success (stack memory per call: 1.2 kB)
• Build 3: success (stack memory per call: 1.2 kB)
• Build 4: success (stack memory per call: 1.2 kB)
• Build 5: success (stack memory per call: 1.2 kB)

---

Commands:

./configure --enable-optimizations --with-lto --enable-shared CC=clang LD=clang
time make -j14
LD_LIBRARY_PATH=$PWD ./python -m test -v test_call

Result: test_call pass successfully and my script outputs stack memory per call: 1.2 kB.

Moreover, the C flags are set as expected in Makefile:

$ grep ^CFLAGS_CEVAL Makefile
CFLAGS_CEVAL= -finline-max-stacksize=512

[vstinner]

LGTM. The fix works as expected according to my manual tests (see above).

In general, I'm not fan of using a specific compiler option depending on the compiler veresion. In this case, I'm fine with it, it's a good trade-off.

[Fidget-Spinner]

Thanks @vstinner for the very thorough testing and review :).

[miss-islington-app]

Thanks @Fidget-Spinner for the PR 🌮🎉.. I'm working now to backport this PR to: 3.14.
🐍🍒⛏🤖

[bedevere-app]

GH-148349 is a backport of this pull request to the 3.14 branch.