Почему простое использование ostringstream генерирует так много ассемблерного кода?

Рассмотрим следующий простой пример, который форматирует строку и целое число, используя ostringstream и отбрасывает вывод:

#include <sstream>

void ostringstream_test() {
std::ostringstream ss;
ss << "x = " << 42;
ss.str();
}

Компилируя это с clang++ -S -O3 -DNDEBUG -std=c++14 test.cc генерирует тонну ассемблерного кода (пол килобайта в инструкциях x86-64 по сравнению с менее чем ста байтами для аналогичного sprintf код) — см. ниже вывод. Почему он генерирует так много кода, это присуще ostringstream API или этот конкретный компилятор / библиотека делает что-то не так?

    .globl  __Z18ostringstream_testv
.p2align    4, 0x90
__Z18ostringstream_testv:               ## @_Z18ostringstream_testv
Lfunc_begin0:
.cfi_startproc
.cfi_personality 155, ___gxx_personality_v0
.cfi_lsda 16, Lexception0
## BB#0:
pushq   %rbp
Lcfi0:
.cfi_def_cfa_offset 16
Lcfi1:
.cfi_offset %rbp, -16
movq    %rsp, %rbp
Lcfi2:
.cfi_def_cfa_register %rbp
pushq   %r15
pushq   %r14
pushq   %r13
pushq   %r12
pushq   %rbx
subq    $328, %rsp              ## imm = 0x148
Lcfi3:
.cfi_offset %rbx, -56
Lcfi4:
.cfi_offset %r12, -48
Lcfi5:
.cfi_offset %r13, -40
Lcfi6:
.cfi_offset %r14, -32
Lcfi7:
.cfi_offset %r15, -24
leaq    -256(%rbp), %r14
leaq    -360(%rbp), %r12
movq    __ZTCNSt3__119basic_ostringstreamIcNS_11char_traitsIcEENS_9allocatorIcEEEE0_NS_13basic_ostreamIcS2_EE@GOTPCREL(%rip), %rax
leaq    24(%rax), %rcx
movq    %rcx, -368(%rbp)
addq    $64, %rax
movq    %rax, -256(%rbp)
Ltmp0:
movq    %r14, %rdi
movq    %r12, %rsi
callq   __ZNSt3__18ios_base4initEPv
Ltmp1:
## BB#1:
movq    $0, -120(%rbp)
movl    $-1, -112(%rbp)
movq    __ZTVNSt3__119basic_ostringstreamIcNS_11char_traitsIcEENS_9allocatorIcEEEE@GOTPCREL(%rip), %rbx
leaq    24(%rbx), %r13
movq    %r13, -368(%rbp)
addq    $64, %rbx
movq    %rbx, -256(%rbp)
Ltmp3:
movq    %r12, %rdi
callq   __ZNSt3__115basic_streambufIcNS_11char_traitsIcEEEC2Ev
Ltmp4:
## BB#2:
movq    __ZTVNSt3__115basic_stringbufIcNS_11char_traitsIcEENS_9allocatorIcEEEE@GOTPCREL(%rip), %r15
addq    $16, %r15
movq    %r15, -360(%rbp)
movq    $0, -272(%rbp)
movq    $0, -280(%rbp)
movq    $0, -288(%rbp)
movq    $0, -296(%rbp)
movl    $16, -264(%rbp)
xorps   %xmm0, %xmm0
movaps  %xmm0, -80(%rbp)
movq    $0, -64(%rbp)
Ltmp6:
leaq    -80(%rbp), %rsi
movq    %r12, %rdi
callq   __ZNSt3__115basic_stringbufIcNS_11char_traitsIcEENS_9allocatorIcEEE3strERKNS_12basic_stringIcS2_S4_EE
Ltmp7:
## BB#3:
testb   $1, -80(%rbp)
je  LBB0_5
## BB#4:
movq    -64(%rbp), %rdi
callq   __ZdlPv
LBB0_5:
Ltmp9:
leaq    L_.str(%rip), %rsi
leaq    -368(%rbp), %rdi
movl    $4, %edx
callq   __ZNSt3__124__put_character_sequenceIcNS_11char_traitsIcEEEERNS_13basic_ostreamIT_T0_EES7_PKS4_m
Ltmp10:
## BB#6:
Ltmp11:
movl    $42, %esi
movq    %rax, %rdi
callq   __ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEElsEi
Ltmp12:
## BB#7:
Ltmp13:
leaq    -104(%rbp), %rdi
movq    %r12, %rsi
callq   __ZNKSt3__115basic_stringbufIcNS_11char_traitsIcEENS_9allocatorIcEEE3strEv
Ltmp14:
## BB#8:
testb   $1, -104(%rbp)
je  LBB0_10
## BB#9:
movq    -88(%rbp), %rdi
callq   __ZdlPv
LBB0_10:
movq    %r13, -368(%rbp)
movq    %rbx, -256(%rbp)
movq    %r15, -360(%rbp)
testb   $1, -296(%rbp)
je  LBB0_12
## BB#11:
movq    -280(%rbp), %rdi
callq   __ZdlPv
LBB0_12:
movq    %r12, %rdi
callq   __ZNSt3__115basic_streambufIcNS_11char_traitsIcEEED2Ev
movq    __ZTTNSt3__119basic_ostringstreamIcNS_11char_traitsIcEENS_9allocatorIcEEEE@GOTPCREL(%rip), %rsi
addq    $8, %rsi
leaq    -368(%rbp), %rdi
callq   __ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEED2Ev
movq    %r14, %rdi
callq   __ZNSt3__19basic_iosIcNS_11char_traitsIcEEED2Ev
addq    $328, %rsp              ## imm = 0x148
popq    %rbx
popq    %r12
popq    %r13
popq    %r14
popq    %r15
popq    %rbp
retq
LBB0_13:
Ltmp8:
movq    %rax, -48(%rbp)         ## 8-byte Spill
testb   $1, -80(%rbp)
je  LBB0_18
## BB#14:
movq    -64(%rbp), %rdi
callq   __ZdlPv
testb   $1, -296(%rbp)
jne LBB0_19
jmp LBB0_20
LBB0_16:
Ltmp5:
movq    %rax, -48(%rbp)         ## 8-byte Spill
jmp LBB0_21
LBB0_15:
Ltmp2:
movq    %rax, -48(%rbp)         ## 8-byte Spill
jmp LBB0_22
LBB0_17:
Ltmp15:
movq    %rax, -48(%rbp)         ## 8-byte Spill
movq    %r13, -368(%rbp)
movq    %rbx, -256(%rbp)
movq    %r15, -360(%rbp)
LBB0_18:
testb   $1, -296(%rbp)
je  LBB0_20
LBB0_19:
movq    -280(%rbp), %rdi
callq   __ZdlPv
LBB0_20:
movq    %r12, %rdi
callq   __ZNSt3__115basic_streambufIcNS_11char_traitsIcEEED2Ev
LBB0_21:
movq    __ZTTNSt3__119basic_ostringstreamIcNS_11char_traitsIcEENS_9allocatorIcEEEE@GOTPCREL(%rip), %rsi
addq    $8, %rsi
leaq    -368(%rbp), %rdi
callq   __ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEED2Ev
LBB0_22:
movq    %r14, %rdi
callq   __ZNSt3__19basic_iosIcNS_11char_traitsIcEEED2Ev
movq    -48(%rbp), %rdi         ## 8-byte Reload
callq   __Unwind_Resume
Lfunc_end0:
.cfi_endproc
.section    __TEXT,__gcc_except_tab
.p2align    2
GCC_except_table0:
Lexception0:
.byte   255                     ## @LPStart Encoding = omit
.byte   155                     ## @TType Encoding = indirect pcrel sdata4
.asciz  "\303\200"              ## @TType base offset
.byte   3                       ## Call site Encoding = udata4
.byte   65                      ## Call site table length
Lset0 = Ltmp0-Lfunc_begin0              ## >> Call Site 1 <<
.long   Lset0
Lset1 = Ltmp1-Ltmp0                     ##   Call between Ltmp0 and Ltmp1
.long   Lset1
Lset2 = Ltmp2-Lfunc_begin0              ##     jumps to Ltmp2
.long   Lset2
.byte   0                       ##   On action: cleanup
Lset3 = Ltmp3-Lfunc_begin0              ## >> Call Site 2 <<
.long   Lset3
Lset4 = Ltmp4-Ltmp3                     ##   Call between Ltmp3 and Ltmp4
.long   Lset4
Lset5 = Ltmp5-Lfunc_begin0              ##     jumps to Ltmp5
.long   Lset5
.byte   0                       ##   On action: cleanup
Lset6 = Ltmp6-Lfunc_begin0              ## >> Call Site 3 <<
.long   Lset6
Lset7 = Ltmp7-Ltmp6                     ##   Call between Ltmp6 and Ltmp7
.long   Lset7
Lset8 = Ltmp8-Lfunc_begin0              ##     jumps to Ltmp8
.long   Lset8
.byte   0                       ##   On action: cleanup
Lset9 = Ltmp9-Lfunc_begin0              ## >> Call Site 4 <<
.long   Lset9
Lset10 = Ltmp14-Ltmp9                   ##   Call between Ltmp9 and Ltmp14
.long   Lset10
Lset11 = Ltmp15-Lfunc_begin0            ##     jumps to Ltmp15
.long   Lset11
.byte   0                       ##   On action: cleanup
Lset12 = Ltmp14-Lfunc_begin0            ## >> Call Site 5 <<
.long   Lset12
Lset13 = Lfunc_end0-Ltmp14              ##   Call between Ltmp14 and Lfunc_end0
.long   Lset13
.long   0                       ##     has no landing pad
.byte   0                       ##   On action: cleanup
.p2align    2

4

Решение

Наиболее вероятная причина различий заключается в том, что реализация IOStream расширяется, а sprintf() Использование это просто вызов функции. Ничто по своей сути не мешает реализации IOStreams библиотекой. Тем не менее, это требует небольшой абстракции и планирования: определение в стандарте использует шаблоны. Обычно они просто встроены. Объявление обычно используемых экземпляров (для типов символов char а также wchar_t) как extern Шаблоны и их явная реализация — это дополнительная работа. Я давно показал, что он окупается с точки зрения времени компиляции и, по крайней мере, libstdc ++ предопределяет функции IOStreams в библиотеке. Судя по вашему эксперименту, libc ++ этого не делает.

2

Другие решения

Других решений пока нет …

По вопросам рекламы [email protected]