This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients arhadthedev, gdr@garethrees.org, lemburg, mark.dickinson, rhettinger, vstinner
Date 2021-11-15.09:54:48
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1636970089.22.0.507206436544.issue45476@roundup.psfhosted.org>
In-reply-to
Content
I don't understand what you are trying to prove about compilers not inlining when you explicitly ask them... not to inline.

The purpose of the -O0 option is to minimize the build time, with a trade-off: don't expect the built executable to be fast. If you care about Python performance... well, don't use -O0? Python ./configure --with-pydebug builds Python with -Og which is not -O0. The -Og level is special, it's a different trade-off between the compiler build time and Python runtime performance.

If you want a Python debug build (Py_DEBUG macro defined, ./configure --with-pydebug), it's perfectly fine to build it with -O2 or -O3 to make sure that static inline functions are inlined. You can also enable LTO and PGO on a debug build.

GCC -Og option:
"""
-Og

    Optimize debugging experience. -Og should be the optimization level of choice for the standard edit-compile-debug cycle, offering a reasonable level of optimization while maintaining fast compilation and a good debugging experience. It is a better choice than -O0 for producing debuggable code because some compiler passes that collect debug information are disabled at -O0.

    Like -O0, -Og completely disables a number of optimization passes so that individual options controlling them have no effect. Otherwise -Og enables all -O1 optimization flags except for those that may interfere with debugging:

    -fbranch-count-reg  -fdelayed-branch 
    -fdse  -fif-conversion  -fif-conversion2  
    -finline-functions-called-once 
    -fmove-loop-invariants  -fmove-loop-stores  -fssa-phiopt 
    -ftree-bit-ccp  -ftree-dse  -ftree-pta  -ftree-sra
"""
https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html

I prefer to use gcc -O0 when I develop on Python because the build time matters a lot in my very specific use case, and gcc -O0 is the best to debug Python in a debugger. See my article:
https://developers.redhat.com/articles/2021/09/08/debugging-python-c-extensions-gdb

On RHEL8, the Python 3.9 debug build is now built with -O0 to be fully usable in gdb (to debug C extensions).

In RHEL, the main motivation to use -O0 rather than -Og was to get a fully working gdb debugger on C extensions. With -Og, we get too many <optimized out> values which are blocking debugging :-(
History
Date User Action Args
2021-11-15 09:54:49vstinnersetrecipients: + vstinner, lemburg, rhettinger, mark.dickinson, gdr@garethrees.org, arhadthedev
2021-11-15 09:54:49vstinnersetmessageid: <1636970089.22.0.507206436544.issue45476@roundup.psfhosted.org>
2021-11-15 09:54:49vstinnerlinkissue45476 messages
2021-11-15 09:54:48vstinnercreate