memset векторизовать получилось - уже хорошо

Так мы про библиотечные функции говорим, или про пользовательский код?

Ну вот взять тот же Hermes. По моему у него как раз необходимый минимум:
https://github.com/facebook/hermes/tree/master/lib/Optimizer/Scalar

В пользовательском коде наверняка будут аналогичные функции в достаточном количестве. А если делать единообразно, то не будет разницы.

Так его и руками можно оптимизировать если конечно своя stdlib

Можно. Но кажется такую векторизацию написать незначительно сложнее, чем оптимизнуть руками.

О, есть что-нибудь почитать по инлайнингу? Когда, к примеру его лучше не делать (instruction cache или что-то еще?), когда от него него наоборот профит очень важен (e.g. c++ vtables), и т.д.

Если так подумать, то я не знаю ни одной серьёзной оптимизации, на которую бы ушло "20% усилий". Но в целом самые необходимые оптимизации - это inline, softpipe (или аналогичные цикловые, при этом на x86 это будет векторизация). Ну и нормальное планирование, разумеется. Остальные оптимизации либо подготавливают контекст для них, либо получают контекст после них

Опять же, как сделал условный memset, появляется простая возможность сделать условный memcpy.

Для того чтобы для vtable применить inline, нужно написать не самую простую девиртуализацию. Но если виртуальный вызов в горячем коде, то эффект будет очень сильным

К сожалению у меня сугубо практический опыт и изучение уже готовых имплементаций. Так что сосоветовать чтиво не смогу, но могу поделиться некоторыми нюансами если интерестно, например о том на каие эвристики можно разделить анализ для инлайна. А вообще конечно нету идеальной и быстрой эвристики, это всегда некий компромисс

Плюсую. Эвристики очень зависят от того как устроен конкретный компилятор. Есть несколько статей о том кто и как реализовывал Inline в своих конкретных системах

Конечно, все зависит от контекста. И в соотв. контексте сама постановка вопроса по поводу 80/20, на мой взгляд, вполне уместна.
В первую очередь, поиск "джентльменского набора" оправдан там, где нужны легковесные методы компиляции.
Это различные системы частичных вычислений и стадийного программирования, JIT-компиляторы, DSL и спецпроцессоры.

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

deforestation важная в контексте ФП.

Что за нумерация значений у Ершова? Я читал некоторые книги Ершова, как я понял, там описывались некоторые вещи, похожие на SSA. Также там большое внимание уделялось частичным вычислениям.

Это разные темы. Числа Ершова нужны для размещения данных по регистрам. А частичными вычислениями он занимался в контексте поиска математической модели алгоритмов (вычислимых функций).

В английской терминологии это value numbering, она описана в любом учебнике по оптимизирующим компиляторам.
VN одновременно может производить свертку и продвижение констант, упрощение выражений, экономию выражений (CSE), а также может быть основой для очень эффективного алгоритма построения SSA.

Нет, числа Ершова это несколько иное :)

Для архитектур с ограниченным количеством регистров (читай x86) ключевой может оказаться фаза распределения регистров. Беда в том, что оптимизации вроде инлайнига и CSE с регаллокатором плохо дружат.

У Владимира Макарова в его MIR для CRuby была табличка оптимизаций, которые дают 70% скорости gcc

Only the most valuable optimization usage:

* function inlining
* global common sub-expression elimination
* variable renaming
* register pressure sensitive loop invariant code motion
* sparse conditional constant propagation
* dead code elimination
* code selection
* fast register allocator with implicit * coalescing hard registers and stack slots for copy elimination

Different optimization levels to tune compilation speed vs generated code performance

No SSA (single static assignment form)