gh-112535: Update _Py_ThreadId() to support PowerPC, IBM Z, etc #112553
Conversation
| @@ -261,6 +261,8 @@ _Py_ThreadId(void) | |||
| __asm__ ("mrs %0, tpidrro_el0" : "=r" (tid)); | |||
| #elif defined(__aarch64__) | |||
| __asm__ ("mrs %0, tpidr_el0" : "=r" (tid)); | |||
| #elif define(HAVE_BUILTIN_THREAD_POINTER) | |||
There was a problem hiding this comment.
This line of the public C API which can be used by a C compiler different than the one used to build Python. I don't think that if define(HAVE_BUILTIN_THREAD_POINTER) check is reliable, according to what @colesbury wrote in the issue.
There was a problem hiding this comment.
I wrote "C compiler", but the C API can be parsed by parsers which are not C compiler, but written in any programming language. Moreover, the C API is used in C++.
There was a problem hiding this comment.
Ah got it, let me check :)
There was a problem hiding this comment.
. I don't think that if define(HAVE_BUILTIN_THREAD_POINTER) check is reliable
but the C API can be parsed by parsers which are not C compiler
Yeah, I thought that configuring time checking would be enough but it looks like we should consider 3rd party case.
There was a problem hiding this comment.
Yeah, I'm concerned that the compiler for CPython may be not exactly the same as the compiler for third-party extensions. For example, if we want to use __builtin_thread_pointer() for x86-64, it's available for GCC 11.1+, but an extension might be compiling with an older version of GCC that doesn't support it for that architecture.
Additionally, one thing to be careful of, is that macOS arm64 will successfully compile and run __builtin_thread_pointer(), but it returns the wrong value (CPU id).
PowerPC on GCC still requires a "register variable" https://github.com/bminor/glibc/blob/master/sysdeps/powerpc/nptl/thread_pointer.h (or it can fallback to a portable thread-local implementation, but that would be slower.)
|
Maybe we should have a more global configuration: "if the compiler doesn't support _Py_ThreadId(), use opaque function calls for Py_INCREF/Py_DECREF". Maybe even give a way to opt-out from inline assembly code. |
|
@vstinner, that might be a better strategy. It just seems more difficult than making |
One step forward: with PR #112747, it becomes possible to use the limited C API on a free threading build. It's implemented with opaque function calls for functions which use too "low-level" functions such at the private Later, we can modify the |
_Py_ThreadId()work on PowerPC, IBM Z, etc. #112535