https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113478
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed| |2024-01-18
CC| |hubicka at gcc dot gnu.org
Component|c++ |ipa
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
t.C:35:19: note: Considering inline candidate T D<T>::test() [with T =
char]/231.
Estimating body: T D<T>::test() [with T = char]/231
Known to be false: not inlined, op0 changed
size:4
Estimating body: T D<T>::test() [with T = char]/231
Known to be false: not inlined, op0 changed
size:4
t.C:35:19: missed: will not early inline: int main()/185->T D<T>::test()
[with T = char]/231, call is cold and code would grow by 1
which is because
Analyzing function body size: T D<T>::test() [with T = char]/231
Accounting size:2.00, time:0.00 on new predicate exec:(not
inlined)
BB 2 predicate:(true)
_3 = &MEM[(const struct __atomic_base *)this_1(D)]._M_i;
freq:1.00 size: 0 time: 0
_4 = __atomic_load_1 (_3, 0);
freq:1.00 size: 4 time: 13
_5 = (char) _4;
freq:1.00 size: 0 time: 0
return _5;
freq:1.00 size: 1 time: 2
Will be eliminated by inlining
Accounting size:1.00, time:2.00 on predicate exec:(not inlined)
so the __atomic_load_1 "call"s are not special-cased during size estimation
and we assume you'd get parameter setup and call. Note some targets
might expand this to a call to libatomic (there's also -finline-atomics).
We might want to consider improving heuristics here.
