I wonder whether it would help to give the cold attribute to that
constructor. From the documentation:
The paths leading to call of cold functions within code are marked as
unlikely by the branch prediction mechanism.
Having the branch predictor know which path is likely ought to at least
help branch prediction. A really smart optimizer would de-inline the
cold blocks of an inlined function. I doubt that GCC is that
sophisticated, but maybe it is worth trying it and looking at the
generated code.
Probably de-inlining your cold block requires the extra function you
added. If speed is more important you would want that function to have
the cold attribute so the branch would be predicted correctly and so
that the call to the extra function wouldn't pollute the L1 cache.
Luca Béla Palkovics wrote:
okay it CException::CException(..) doesn't get inlined now..
But it still doesn't inline my CHandleMove::onMove(...) because of the
throw
push rbx
sub rsp, 10h
cmp edx, 3
mov [rdi], rsi
jz short loc_408990
mov edi, 68h
call ___cxa_allocate_exception
mov edx, offset aPacketSizeIsDi ; "Packet size is...
mov esi, 4
mov rdi, rax
mov rbx, rax
call _ZN10CExceptionC1EiPKc ; CException::CException
mov edx, offset _ZN10CExceptionD1Ev ; CException::~CException
mov esi, offset _ZTI10CException ; `typeinfo for'CException
mov rdi, rbx
call ___cxa_throw
add rsp, 10h
pop rbx
retn
When i put the throw into a own function everything thing is fine..looks
like this (and also gets inlined into CHandleMove::onMove(...))
cmp edx, 3
mov [rdi], rsi
jz short locret_408920
jmp _Z14throwWrongSizev ; throwWrongSize(void)
rep retn
.. Its a lot better to put the throw into a own function..
