Во что компилируется C++?

Можно использовать второй или третий уровень оптимизации (-O2/-O3) — так код может оказаться проще для понимания.

Или может есть спец-просмотровщики этого ассемблера, сильно облегчающие его понимание?

Не знаю сильно ли, но с IDA несколько проще рассматривать код.

Я так понимаю, надо делать g++ -S code.cpp и тупо читать асмокод?

Можно добавить -fverbose-asm

-masm=intel

// бомбалейло, го

Что помогает «смотреть на всё это и думать об эффективности юзания кеша»? Валгриндовый кешгринд - это да, но это эмпирический путь.

Изучай cache-oblivious алгоритмы, все остальное - чистая эмпирика

так код может оказаться проще для понимания

а может сложнее из-за инлайнов

https://en.wikipedia.org/wiki/LLVM#LLVM_intermediate_representation

https://en.wikipedia.org/wiki/GNU_Compiler_Collection#GENERIC_and_GIMPLE

AT&T уж куда удобней и читабельней, а почему ви спгашиваете?

Так как вся эта информация есть у GCC и доступна (возможно, не в 100% полном объёме) плагинам, можно такой плагин и написать. Не самое простое занятие, но результаты должны быть наиболее точными, в произвольной форме и для этого не придётся рассматривать ассемблер.

Я для понимания кода использую clang с флагом -S -emit-llvm он так намного понятнее и приятнее его читать. Refference manual по LLVM: http://llvm.org/docs/LangRef.html

AT&T уж куда удобней и читабельней, а почему ви спгашиваете?

Ага, один синтаксис арифметики чего стоит.

$ g++ -std=c++14 -g -c -O3 foo.cc -o foo.o
$ objdump -d -M intel -S foo.o > foo.S

+ бонус https://gcc.godbolt.org/

Читать о том как работает компайлер. Гдето должно быть это описано.

Мне интересно прежде всего:
- заинлайнился метод или функция или нет
- сколько регистров / памяти сожрали аргументы
- как вернулся результат, использовалась ли RVO (Return Value > Optimization) или нет.
- посмотреть на всё это и подумать про эффективность юзания кеша

Компилятор от intel умеет генерить optimization report. Обрати внимание на него

Всё правильно понимаешь.

Про cache-oblivious знаю, даже знаю про Ван Эмде Боас лэйаут!

А почему именно так, с привлечением objdump?

После кодинга на tasm/fasm/masm синтаксис AT&T конечно кажется ущербным. Но в силу его засилья в юниксах, придётся смириться и полюбить.

Учитывая, что хуже tasm/masm сложно что-то найти, gas просто прелестен в сравнении. Nasm и прочие конечно поприятней в целом, но раз уж в gcc gas, то и к AT&T можно привыкнуть, он вполне удобен.

А что с ним не так? Ты ведь о segreg:[base+index*scale+disp] vs %segreg:disp(base,index,scale)?

http://www.imada.sdu.dk/Courses/DM18/Litteratur/IntelnATT.htm

Хотя справедливости ради гцц умеет в интел синтаксис. Но это лишь вопрос привычки.

tasm/fasm/masm

При том что они в мелочах расходятся, все становится не так уж однозначно.

Да, про это, ну и ты уже сам процитировал почему AT&T говно.

Не, понятно, что это всё вкусовщина и субъективщина, но.

Я для понимания кода использую clang с флагом -S -emit-llvm он так намного понятнее и приятнее его читать.

Это более высокий уровень, может ТС хочет на уровне микроархитектуры разбираться, раз уж он в кэши полез

Не вижу говно, вижу эмоции. Шо одно, шо другое — разницы особой нет.

Функции-члены инлайнятся или при явном указании, или когда они определяются в теле класса. Ну, и, конечно же, как компилятор захочет.

читай Соглашения о вызовах, используемые разными компиляторами с языка C++ в разных ОС, и исходники crt0 и libstdc++ — ту часть, которая выполняется до запуска main (запуск констукторов) и после (деструкторов).

ещё в первом приближении напиши объектно-ориентированный хелловорд на языке Vala, скомпилируй его с -C (в hello.c), и посмотри скодогенерированный исходник (с рантаймом GObject, GLib).

примерно в такое вот и компилируется. в первой версии C++ (CFRONT) примерно так всё и работало.

гугли C++ ABI, name mangling, C++ calling convention, исходники C++ runtime

В реальной жизни твой код вероятно будет компилироватьсяс -O2 и мб еще какими ключами, так что их не забудь.

выхлоп с плюсов на асме далеко не самый читабельный. если бы с сишечки - тогда вообще всё просто. а в плюсах много всякого лишнего и компилятор там извращается, как только может и за счёт оптимизаций код становится весьма мало похож на оргинал. если не знать ассемблер хорошо, хрен разберёшься.
и вот это - -masm=intel правильно подсказал анонимус. ибо обычный GAS нечитабелен.

Уж простите, но я вижу только

кококо

над си оптимизатор тоже занатно извращается, от оригинального кода ничего не остаётся

ну, ваше кококо от моего отличается только наличием многолетнего опыта разработки, в моём случае.

Так вот и я о том, почему то люди убившие на что-то много лет жизни, считают, что их позиция куда более верная и обоснованная. И придираются к совершенным мелочам. Между прочим, мир не стоит на месте, каждый год происходит очень значительное развитие в любой сфере.

ну, ваше кококо от моего отличается только наличием многолетнего опыта разработки, в моём случае.

Его кококо отличается от твоего тем, что он прав (и мой опыт разработки не меньше твоего).

Что помогает «смотреть на всё это и думать об эффективности юзания кеша»?

рано тебе об этом думать, судя по вопросу. когда вопросов как смотреть то, что генерирует компилятор, не будет, то может и вопрос про кэш отпадёт. а так - бенчмарки, CPU performance counters, теория итд.

Что помогает «смотреть на всё это и думать об эффективности юзания кеша»? Валгриндовый кешгринд - это да, но это эмпирический путь.

Другого пути измерить что-то, кроме эмпирического, нет. Другое дело, делать соответствующие поправки в код, но без измерений они бессмысленны

radare2?

проходит. говнокодеров становится больше. пока я наблюдаю, что языки развиваются, а навыки программирования падают. впрочем, это относится не только к программированию. во всех инженерных профессиях происходит падение уровня владения предметом.