This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug tree-optimization/46228] code produced for STL container is worse in 4.5.1 than in 4.4.5


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46228

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |missed-optimization
           Severity|normal                      |enhancement

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> 2010-10-29 20:42:41 UTC ---
Considering std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
_Alloc>::~_Rb_tree() [with _Key = int, _Val = int, _KeyOfValue =
std::_Identity<int>, _Compare = std::less<int>, _Alloc = std::allocator<int>]
with 4 size
 to be inlined into int main() in
/home/apinski/local-gcc/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_set.h:87
 Estimated growth after inlined into all callees is +2 insns.
 Estimated badness is 3, frequency 1.00.
 inline_failed:call is unlikely and code size would grow.

...
Considering std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
_Alloc>::~_Rb_tree() [with _Key = int, _Val = int, _KeyOfValue =
std::_Identity<int>, _Compare = std::less<int>, _Alloc = std::allocator<int>]
with 4 size
 to be inlined into int main() in
/home/apinski/local-gcc/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_set.h:87
 Estimated growth after inlined into all callees is +2 insns.
 Estimated badness is 118, frequency 0.00.
 inline_failed:call is unlikely and code size would grow.


I bet we don't take into account that the argument to ~_Rb_tree is an
ADDR_EXPR.  First I noticed it saying the call is unlikely which is true but
the thing that is not true is the +2 insns; only because of the arguments being
passed is an ADDR_EXPR of a component_ref of a var_decl.  Maybe we should
record if the only places pointer arguments are used is in
MEM_REF/INDIRECT_REF's and then inline functions based on that fact if we have
those arguments as a ADDR_EXPR of a decl.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]