You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the moment we compile releases with -fwrapv which makes the code a bit safer, but disables certain optimizations. From the GCC docs:
This option instructs the compiler to assume that signed arithmetic overflow of addition, subtraction and multiplication wraps around using twos-complement representation. This flag enables some optimizations and disables others.
My experiments with running sanitisers seem to suggest that we are nearly already ready for -fno-wrapv (or -fstrict-overflow in general). Doing so could lead to quite a few speedups, but we would need to be more careful with the code we write.
My plan right now is to adapt the build system so that only the modules that need it are build with -fwrapv, and the rest can be build with -fstrict-overflow.
We already have machinery that can add specific CFLAGS for specific modules only.
Perhaps the whole thing can be gated behind a configure flag.
If everything goes well, and this improves performance we can consider adding this functionality to one of the standard optimization options.
We can also work on making more modules -fstrict-overflow safe.
This is certainly worth exploring! Consider moving the conversation to a cpython issue sooner rather than later, to get feedback from a broader audience.
Activity
matthiasgoergens commentedon Sep 13, 2022
My plan right now is to adapt the build system so that only the modules that need it are build with -fwrapv, and the rest can be build with -fstrict-overflow.
We already have machinery that can add specific CFLAGS for specific modules only.
Perhaps the whole thing can be gated behind a configure flag.
If everything goes well, and this improves performance we can consider adding this functionality to one of the standard optimization options.
We can also work on making more modules -fstrict-overflow safe.
ericsnowcurrently commentedon Sep 13, 2022
This is certainly worth exploring! Consider moving the conversation to a cpython issue sooner rather than later, to get feedback from a broader audience.
matthiasgoergens commentedon Sep 13, 2022
@ericsnowcurrently This grow out of the linked Cpython issue. But I can start a new issue, too, if you think that is better.
markshannon commentedon Sep 14, 2022
I agree, this should be a CPython issue.
matthiasgoergens commentedon Sep 14, 2022
I'm closing this in favour of python/cpython#96821