https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111243
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Version|unknown |13.2.1
Status|UNCONFIRMED |NEW
CC| |hubicka at gcc dot gnu.org,
| |rguenth at gcc dot gnu.org
Last reconfirmed| |2023-08-31
Keywords| |documentation
Ever confirmed|0 |1
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
One of the points of -Og is to make debugging of C++ programs easier and that
absolutely requires some inlining as otherwise you step into a lot of
abstraction stuff. So no, -finline is enabled on purpose for -Og, but it
should only inline where doing that improves code size.
For your example we probably either have wrong estimates or the C++ frontends
indicates we should ignore limits when inlining.
/tmp/t.cpp:14:13: optimized: Inlining Foo::Foo(int)/1 into int Test(int)/3.
Estimating body: Foo::Foo(int)/1
Known to be false: not inlined
size:4
Accounting size:2.00, time:2.00 on predicate exec:(true)
Accounting size:1.00, time:0.41 on predicate exec:(true)
Accounting size:0.50, time:0.20 on predicate exec:(true)
Accounting size:0.50, time:0.30 on predicate exec:(true)
/tmp/t.cpp:14:13: note: Inlining Foo::Foo(int)/1 to int Test(int)/3 with
frequency 1.00
We estimate a growth of one which is visible by setting --param
early-inlining-insn=0:
/tmp/t.cpp:14:13: note: Considering inline candidate Foo::Foo(int)/1.
Estimating body: Foo::Foo(int)/1
Known to be false: not inlined
size:4
Estimating body: Foo::Foo(int)/1
Known to be false: not inlined
size:4
/tmp/t.cpp:14:13: missed: will not early inline: int
Test(int)/3->Foo::Foo(int)/1, growth 1 exceeds --param early-inlining-insns
with --param early-inlining-insns=1 we still inline. I guess it makes sense
to adjust this param by default for -Og (and to zero). The intent is
to inline things like get() and set(x) in
struct X { int get() { return val; } void set(int v) { val = v; } int val; };
or other simple forwarders.
Would you agree with inlining these? -Og is also documented to shift the
balance a bit towards performance compared to -O0 which for C++ code
necessarily means at least some inlining. Possibly we should also amend
the documentation highlighting this.
