Я в ходе обсуждения потерял что именно должен искать этот

статический анализ. У меня есть предположение, что "инженерный" способ решения задачи - это переход на динамический анализ.

Соответственно вопрос - какие именно проблемы предполагается искать?

В целом, я агитирую за композиционный анализ и против whole-program вне зависимости от того, что он ищет. 😊

Как человек, долго работавший в парадигме whole program, не соглашусь :) поэтому и интересуюсь, из-за чего конкретно сыр-бор

Я выше описывал свои претензии. Whole-program не масштабируется, что приводит к ряду проблем down the line.

Я имею представление о проблемах. Whole-program спокойно тянет несколько миллионов строк плюсового кода (и это в однопоток!). Весь вопрос только в том, на сколько он нужен для решения конкретной задачи

И что же он там находит? 😊

Несколько миллионов строк плюсового кода и находит.

У нас он для alias анализа используется, для девиртуализации и inline. Также находит нарушения strict-aliasing. Это то, что навскидку приходит в голову

Звучит как кусок компилятора. У Вас whole-program C++ compiler?

Да, это компилятор. Поэтому я и говорю что для whole program надо смотреть, что именно ищется

Whole-program C++ compiler, который "спокойно тянет несколько миллионов строк кода"?

Скажем так, там есть, куда оптимизировать, но спеки без проблем. Были сложные проекты с проблемами скорости компиляции, но там чисто технические проблемы, которые решились

девиртуализация? это имеет отношения к vtable?

Опосредованное. Но да, это замена виртуальных вызовов на вызовы по имени

Кажется, кроме как верить на слово других вариантов нет? 😊

Какой конкретно из пунктов следует подтвердить? То, что спеки 2017 эльбрусовских компилятором собираются в whole program вроде давно известно, при необходимости могу поискать. Не уверен, что там есть тесты более миллиона строк, но более 300 тыс были. Сам себя компилятор, так собирал, а это уже более 2 млн строк. Подтверждений не будет. По внешнему проекту размером более 2 млн строк подтверждений не будет (не могу найти в открытых источниках про какой именно режим они пишут)

За какое время хоть собирал-то? 😊

В несколько раз дольше гцц)

Алекс, вы распараллеливаете? Там стат-анализ используется для отлова разных проблем в OCaml. Поскольку OCaml очень хорошо спроектирован по сравнению с С++, то из PVS-овской кучи ошибок остаётся ну процентов 10. А ведь чем меньше нужно проблем покрывать, тем меньше abstract domain => тем быстрее проходит анализ.

Это не то, что я бы назвал "спокойно тянет", не в контексте статического анализа кода в дополнение к компиляции. 😊

Нет. По крайней мере на момент несколько лет назад. Но распарралеливание для реальных проектов очень нужно

Это lcc, ваш неуловимый Джо? А начиная с какой версии?

Эммм, на whole-program как базовый режим сборки спеков перешли году в 14-15, наверное

Я думаю, что на ОКамле распараллеливание будет проще сделать. Но, насколько я понял, это ещё очень исследовательская задача.

Задача вполне инженерная, просто рук для неё не хватает

Я не столь оптимистичен. Для этого нужно понимать, как хорошо параллелить fix-point вычисления на типичном control flow graph. То есть, вы, конечно, сможете сделать решётку, бросать какие-то green threads для подсчёта каких-то обновлений на локальных участках кода, но будет ли это эффективно? Не потеряете ли вы на синхронизации больше, чем получите на распараллеливании? Отмечу, что тот же yukari - это 32 потока. Простую-то вещь на Хаскеле на столько не враз распараллелишь.