Marc-Andre Lemburg <m...@egenix.com> added the comment:
On 15.11.2021 08:54, Oleg Iarygin wrote:
>
> Oleg Iarygin <o...@arhadthedev.net> added the comment:
>
> Marc-Andre:
>> Inlining is something that is completely under the control of the
> used compilers. Compilers are free to not inline function marked for
> inlining [...]
>
> I checked the following C snippet on gcc.godbolt.org using GCC 4.1.2 and
> Clang 3.0.0 with <no flags>/-O0/-O1/-Os, and both compilers inline a function
> marked as static inline:
>
> static inline int foo(int a)
> {
> return a * 2;
> }
>
> int bar(int a)
> {
> return foo(a) < 0;
> }
>
> So even with -O0, GCC from 2007 and Clang from 2011 perform inlining. Though,
> old versions of CLang leave a dangling original copy of foo for some reason.
> I hope a linker removes it later.
That's a great website :-) Thanks for sharing.
However, even with x86-64 gcc 11.2, I get assembler which does not inline
foo() without compiler options or with -O0: https://gcc.godbolt.org/z/oh6qnffh7
Only with -O1, the site reports inlining foo().
> As for other compilers, I believe that if somebody specifies -O0, that person
> has a sound reason to do so (like per-line debugging, building precise flame
> graphs, or other specific scenario where execution performance does not
> matter), so inlining interferes here anyway.
Sure, but my point was a different one: even with higher optimization
levels, the compiler can decide whether or not to inline. We expect
the compiler to inline, but cannot be sure.
With macros the compiler has no choice and we are in control and even
when using -O0, you will still want e.g. Py_INCREF() and Py_DECREF()
inlined.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue45476>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
