Allow C11 feature: alignas

[encukou]

Let's allow the alignas specifier in public headers, as _Py_ALIGN_AS.
Start with the free-threaded build to limit impact.

Right now, this would help PyASCIIObject retain pre-3.14 ABI (which is not guaranteed but was stable for a long time, and was requested in python/cpython#128972), while supporting free-threaded builds (where interned can't be a bitfield).channel.

To retain compatibility with C99 and older C++ on supported platforms (which we don't guarantee), spell this _Py_ALIGN_AS and define it with a monster macro like this (details might change of course):

#ifdef Py_GIL_DISABLED
#   ifndef _Py_ALIGN_AS
#       ifdef __cplusplus
#           if (__cplusplus < 201103L) \
                  && (defined(__GNUC__) || defined(__clang__))
#               define _Py_ALIGN_AS(V) __attribute__((aligned(V)))
#           else
#               define _Py_ALIGN_AS(V) alignas(V)
#           endif
#       elif defined(__STDC_VERSION__) && __STDC_VERSION__ >= 202311L
#           define _Py_ALIGN_AS(V) alignas(V)
#       elif defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201112L
#           define _Py_ALIGN_AS(V) _Alignas(V)
#       elif (defined(__GNUC__) || defined(__clang__)) \
              && defined(__STDC_VERSION__) && __STDC_VERSION__ < 201112L
#           define _Py_ALIGN_AS(V) __attribute__((aligned(V)))
#       elif defined(_MSC_VER)
#           define _Py_ALIGN_AS(V) __declspec(align(V))
#       else
#           define _Py_ALIGN_AS(V) _Alignas(V)
#       endif
#   endif
#endif

(Note that when porting to unsupported platform, users can use -D_Py_ALIGN_AS= with their own spelling.)

PoC (shared with #59): https://github.com/python/cpython/pull/130697/files#diff-c33c79e156be4137aeaaa15bf4b5c7f023a78b6a54abd2d519e7cc88caed2cca

Vote: Allow this for the free-threaded build

• @encukou
• @erlend-aasland
• @mdboom
• @serhiy-storchaka
• @vstinner
• @zooba

Vote: Allow this always

Should we later remove the #ifdef Py_GIL_DISABLED without another vote?
(I'm not looking to do this right now, but if we all agree, the WG won't need to revisit this.)

• @encukou
• @erlend-aasland
• @mdboom
• @serhiy-storchaka
• @vstinner
• @zooba

[zooba]

Right now, this would help PyASCIIObject retain pre-3.14 ABI ... while supporting free-threaded builds (where interned can't be a bitfield).

Seems like this case probably needed a compare-and-swap¹ rather than an atomic write? Changing the layout of the bitfields is as much an ABI break as changing the size. It also wouldn't surprise me to find architectures in the future that require even wider values for atomic operations - what do we do then?

Start with the free-threaded build to limit impact.

It's a macro definition, there'd better be no impact from merely defining it 😉 I'd vote for just adding it without the condition. Splitting it between two builds is unnecessary, and when we merge free-threaded back into main then we're going to have to evaluate and manage the ABI breakage again anyway (though minimising ABI breaking in main is a good idea right now, so that if we don't merge free-threading back in then nobody suffers).

Is it drastically better/worse than adding _reserved members? How often do we want to do alignment with compiler semantics rather than semantics we can choose? When we later want to use the space, it's easier and safer to rename a _reserved.

All that said, if we were to allow alignment specifiers, this looks like the right way to do it. I'm just not convinced they're the best or only way to solve the problem here.

Footnotes

1. With a careful, non-ABI changing union added to provide a swappable-size member in the same location as the field. Good argument for putting bitfields in their own struct. ↩

[encukou]

The free-threading PyObject ABI is different, so I'm not too worried about the PyUnicode one. Also, changing free-threading ABI doesn't break existing projects: they'll have some time to adapt before free-threaded becomes default.

In the future, let's hide the structs.

I'd vote for just adding it without the condition.

Then vote for both, now :)
I worry that if it's just defined, some dev can add it to non-free-threaded build after RC, and break builds on some exotic compiler.

Is it drastically better/worse than adding _reserved members?

It's not platform-specific :)

I'm just not convinced they're the best or only way to solve the problem here.

Yeah, it's just the most convenient one. A relatively harmless way to introduce a C11 feature.

[vstinner]

Ping @mdboom @serhiy-storchaka.

[mdboom]

I'm in favor. I'd even be in favor of doing this on both GIL/non-GIL build immediately -- there are some performance issues related to alignment that this would be handy for.

[serhiy-storchaka]

👍

[encukou]

I'd even be in favor of doing this on both GIL/non-GIL build immediately -- there are some performance issues related to alignment that this would be handy for.

Could you give me an easy example? :)
We voted to do this when needed, so if there's currently a struct where it would be useful, let's do it.

[encukou]

As of #133085, _Py_ALIGN_AS is in main; so far only used for free-threaded builds.
The first PR that needs it for regular builds can add it (perhaps python/cpython#130771 does).