https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111243
--- Comment #2 from Alex Mohr <amohr at amohr dot org> ---
Thanks much for looking at this, Richard.
I definitely understand what you're driving at with regard to stepping into
lots of C++ abstraction stuff. But I think it gets blurry trying to
distinguish what's interesting to a human or not based on code size.
I think I could probably be convinced about inlining trivial getters, setters,
and forwarders like in your struct X. But I think code size doesn't work as the
deciding factor here. Just to illustrate, here's a modified example with '-Og
--param early-inlining-insns=0'. The entire thing gets inlined, even though
every small function contains a conditional, and one even calls another:
struct Foo {
explicit Foo(int in) { m = in > 0 ? in : 0; }
int CalcFoo() const { int r = CalcBar(); return r < 0 ? -r : r; }
int CalcBar() const { return m > 20 ? 20 : m; }
int m;
};
int Test(int in) {
Foo f(in);
return f.CalcFoo() + f.CalcBar();
}
----------------------
Test(int):
test edi, edi
mov eax, 0
cmovs edi, eax
mov eax, 20
cmp edi, eax
cmovg edi, eax
lea eax, [rdi+rdi]
ret
https://godbolt.org/z/hcsnzMrP9
On one hand it's awesome that the optimizer is so good... but this could be
pretty frustrating to debug.
Just FWIW when I compile with '-O0', I see a ~5x slowdown vs '-O2', but with
'-Og -fno-inline', I see just ~4x, so it's still a nice win over '-O0'.
