После шести месяцев разработки представлен (http://lists.llvm.org/pipermail/llvm-dev/2019-March/131157.h... релиз проекта LLVM 8.0 (http://llvm.org/) (Low Level Virtual Machine) - GCC-совместимого инструментария (компиляторы, оптимизаторы и генераторы кода), компилирующего программы в промежуточный биткод RISC-подобных виртуальных инструкций (низкоуровневая виртуальная машина с многоуровневой системой оптимизации). Сгенерированный псевдокод может быть преобразован при помощи JIT-компилятора в машинные инструкции непосредственно в момент выполнения программы.Из новых возможностей LLVM 8.0 отмечается включение защиты от атак Spectre, поддержка распараллеленной компиляции в ORC JIT, стабилизация компиляции в WebAssembly, добавление в Clang опции для инициализации автоматически распределяемых переменных, улучшение предкомпиляции и поддержка флага /Zc:dllexportInlines в clang-cl, поддержка архитектуры RISC-V в компоновщике lld, расширение средств диагностики.
Улучшения (http://releases.llvm.org/8.0.0/tools/clang/docs/ReleaseNotes... в Clang 8.0:
- Добавлена возможность инициализации автоматически распределяемых переменных (https://en.wikipedia.org/wiki/Automatic_variable) (например, локальных переменных, определённых внутри конструкций). По умолчанию автоматические переменные остаются неинициализированными. Инициализация осуществляется при указании опции "-ftrivial-auto-var-init=pattern" и позволяет избавиться от некоторых форм неопределённого поведения, вызванных заполнением переменных случайными остаточными данными из стека и регистров. Для принудительного отключения инициализации, например, для больших массивов, предусмотрен атрибут "dont_initialize_me";
- Добавлена поддержка файлов повторного сопоставления данных профилировния (profile-remapping (http://releases.llvm.org/8.0.0/tools/clang/docs/UsersManual.... которые позволяют сопоставить символьные имена и данные профилирования для использования ранее сгенерированных профилей выполнения с другой версией программы с изменёнными таблицами символов (например, из-за переименования класса или пространства имён);- Добавлены новые диагностические опции: "-Wextra-semi-stmt" для выявления лишних ";" и "-Wempty-init-stmt" для выявления пустых блоков инициализации в конструкциях if, switch и for;
- Помимо ранее добавленной защиты Retpoline в состав включены изменения (http://releases.llvm.org/8.0.0/docs/SpeculativeLoadHardening... для генерации последовательностей инструкций для получения данных из памяти с блокированием утечек, вызванных спекулятивным выполнением инструкций в современных CPU. Защита может быть выборочно включена или отключена для определённых функций через указание атрибутов speculative_load_hardening и no_speculative_load_hardening, а также включена глобально при помощи опции "-mspeculative-load-hardening";
- Добавлены опции "-fprofile-filter-files=[regexes]" и "-fprofile-exclude-files=[regexes]" для выборочной фильтрации или исключения определённых файлов с данными профилирования в формате gcov;
- В clang-cl, альтернативном интерфейсе командной строки, обеспечивающем совместимость на уровне опций с компилятором cl.exe из состава Visual Studio, добавлена поддержка опций "/Yc" и "/Yu" для предварительной компиляции заголовочных файлов. Добавлена поддержка флага "/Zc:dllexportInlines", аналогичного флагу "-fvisibility-inlines-hidden", для неприменения атрибутов dllexport и dllimport к inline-функциям;
- Обеспечена возможность использования инструментов Address Sanitizer и Undefined Behaviour Sanitizer с MinGW;
- Расширены возможности, связанные с поддержкой OpenCL, OpenMP и CUDA. В том числе добавлены некоторые новые возможности OpenMP 5.0 и расширены средства диагностики;
- Расширены возможности UBSan (Undefined Behavior Sanitizer), детектора неопределенного поведения (http://ru.wikipedia.org/wiki/%D0%9D%D0%B... выявляющего во время выполнения программы ситуации, когда поведение программы становится неопределенным. Расширен спектр ситуаций, охватываемых в режиме "-fsanitize=implicit-conversion" (Implicit Conversion Sanitizer), например, добавлено выявление проблем с составными операторами присваивания и обеспечено определение неявных изменений знака целых чисел ("-fsanitize=implicit-integer-sign-change"). При проверке выравнивания теперь выполняется проверка атрибутов, подобных "assume_aligned";
Основные новшества LLVM 7.0:
- Снят флаг экспериментальной разработки с целевой платформы WebAssembly, поддержка которой теперь включена по умолчанию и не требует указания опции LLVM_EXPERIMENTAL_TARGETS_TO_BUILD. В разряд стабильных также переведены формат объектных файлов и C ABI для платформы WebAssembly. Экспериментальной пока остаётся только поддержка многопоточности в WebAssembly;
- В утилиту llvm-cov добавлена опция "-format=lcov" для экспорта coverage-статистики в формате lcov;- Добавлена опция "-x86-discriminate-memops", использующая отладочную информацию для точной идентификации инструкций x86 с обращающимися к памяти операндами для упреждающей загрузки в кэш (https://lists.llvm.org/pipermail/llvm-dev/2018-November/1274... (cache prefetching (https://en.wikipedia.org/wiki/Cache_prefetching));
- В libFuzzer добавлена поддержка платформы Windows (x86_64);
- JIT API для компиляции по запросу (ORC, On Request Compilation) добавлена поддержка параллельной компиляции. Старый однопоточный API объявлен устаревшим, переименован в LegacyIRCompileLayer и будет удалён в LLVM 9. На основе нового API реализован демонстрационный JIT LLJIT. Поддержка MCJIT и ExecutionEngine будет продолжена, но для новых проектов ORC отмечен как предпочтительный JIT API;
- В отладчике LLDB обеспечена подсветка синтаксиса выводимого кода на языке Си. В команде "expression" обеспечено автодополнение ввода табуляцией;
- В бэкенд для архитектуры x86 добавлена поддержка CPU AMD bdver2 на базе микроархитектуры Piledriver. Для указания в опции "-march" добавлен новый идентификатор CPU "cascadelake", идентичный skylake-avx512 с включением дополнительного набора инструкций avx512vnni. Прекращена подстановка инструкции ADCX, которая мало чем отличается от инструкции ADC, но увеличивает размер кода;
- Внесены многочисленные улучшения в бэкенды для архитектур AArch64, ARM, SystemZ, Hexagon, MIPS и PowerPC.URL: http://lists.llvm.org/pipermail/llvm-dev/2019-March/131157.html
Новость: https://www.opennet.ru/opennews/art.shtml?num=50360
Ядро уже им конпелируется?
Да, после того как VLA (Variable Length Arrays) из ядра убрали.
https://clangbuiltlinux.github.io/
https://github.com/nathanchance/android-kernel-clang
> VLAПолезная штука, кстати. Жаль, что нет в стандарте ISO C.
Внезапно они есть с C99, плюс в C11 немного поставили.
Отвратительная штука ибо ты не можешь отследить выделилась память или нет и тупо сваливаешься на переполнении стека
Его это не волнует.
иногда волнует, но также порой волнует потеря циклов 16-мгц контроллера на выделение и освобождение кучи когда на стеке место гарантировано есть. Так что лучше когда есть выбор.
> иногда волнует, но также порой волнует потеря циклов 16-мгц контроллера на выделение
> и освобождение кучи когда на стеке место гарантировано есть. Так что
> лучше когда есть выбор.Вот и меня волнует. А того не волнует, он ведь "не можешь отследить..."
Если ты статически уверен, что памяти на стеке достаточно, значит ты статически знаешь сколько там есть и сколько тебе надо. То есть ты посчитал максимальный размер того, что тебе надо, и убедился в том, что этот максимальный размер возможно выделить. Ну так выдели максимальный, в чём проблема-то?
Твоему 16MHz процессору это может даже приятнее будет, поскольку это может уменьшить количество динамической возни с указателем стека.
А что, в любой программе существует только одна функция с однократным вызовом?Блин, а я потом удивляюсь - почему это браузеры жрут всю доступную память?
в embedded это еще возможно отследить (и очень желательно), в браузере точно уже нет.
> с однократным вызовомне то что с однократным, но нужно следить на каких уровнях вложенности она вызывается и сколько стека для нее осталось
> А что, в любой программе существует только одна функция с однократным вызовом?Если у тебя для нескольких функций достаточно памяти на стеке, то ты ведь для них тоже для всех посчитал, сколько каждая из них выделит максимально? И в сумме получилось меньше стека?
Или ты выяснил, что когда первая функция на стеке выделяет много, все остальные выделяют мало и в сумме всегда выходит меньше стека? Тебе реально приходилось сталкиваться с таким случаем на практике? Расскажи об этом, действительно ведь интересно.
> Блин, а я потом удивляюсь - почему это браузеры жрут всю доступную
> память?Да, ещё и ядро тоже. Они тоже отказались от объектов динамических размеров на стеке. Глубина рекурсии у них по жизни должна была просчитываться статически,
да все понятно что тут аргументов больше против чем за и большой риск нарваться, а за использование vla в сразу нескольких вложенных функциях на разных уровнях я бы тоже по рукам бил больно. С другой стороны, вот например MISRA вносит целую кучу запретов, понятных и не очень, а потом люди встречаются и думают: "а если мы в нашей функции alloca используем, станет ругаться или не заметит?"
А зачем использовать alloca? Если уж совсем никак не уйти от динамического размера, а куча слишком медленная, то можно же сделать специализированный аллокатор под такого рода вещи.
> Ну так выдели максимальныйна самом деле чаще всего так и делаем, хотя не красиво как-то.
Вообще дискуссия не прекращается на эту тему: https://stackoverflow.com/questions/12407754/what-technical-... , http://c-faq.com/malloc/alloca.glb.html
Без VLA происходит то же самое.
Другое дело, что если использоется VLA или alloca, особенно внутри if или цикла, то компилятору труднее оптимизировать, ибо Stack Pointer в пределах функции уже не постоянная величина, и надо либо генерить код, которые учитывает изменения Stack Pointer, либо таки использовать регистр под Frame Pointer, а не под что-то более полезное.
На 64-разрядной архитектуре стек и куча используют одно и то же логическое адресное пространство, поэтому без разницы, где вы будете выделять память, в стеке или в куче -- если память исчерпывается, она исчерпывается как для стека, так и для кучи. А выделять локальную память в стеке быстрее и удобнее.
Вообще да, но для ядра опасненько.
clang не может в C99 / C11 =)
Linux не может в C99 / C11 =)
Еще как может
Тогда почему:
> Ядро уже им конпелируется?
>> Да, после того как VLA (Variable Length Arrays) из ядра убрали.
>>> VLA
>>>>Полезная штука, кстати. Жаль, что нет в стандарте ISO C.
конпелируется, но результат конпеляции гораздо жЫрнее.
Не поленился, собрал.$ du arch/x86/boot/bzImage /usr/src/linux-4.14.83-gentoo/arch/x86/boot/bzImage
7316 arch/x86/boot/bzImage
7164 /usr/src/linux-4.14.83-gentoo/arch/x86/boot/bzImage$ find . -name '*.ko' | xargs du -c | tail -n 1
4628 итого
$ find /usr/src/linux-4.14.83-gentoo/ -name '*.ko' | xargs du -c | tail -n 1
4504 итогоТот что локально собран clang'ом, в /usr/src при помощи gcc. Вывод: clang делает жирнее, то эта дополнительная жирность 2-3%. Не тянет на "гораздо" ведь, не?
Что-то очень мало фич, результат погони за версиями?
Ожидаем, растоманы здеся)
Для тех, кто желает использовать новый LLVM-8.0.0 совместно с Mesa-18.3.2 на FreeBSD, достаточно в /etc/make.conf задать следующие параметры:DEFAULT_VERSIONS+=llvm=80
MESA_LLVM_VER=${LLVM_DEFAULT}и перекомпилировать Mesa:
portmaster -gD mesa-
Должно оказаться что-то вроде такого:
% pkg info -r llvm80
llvm80-8.0.0:
mesa-dri-18.3.2_2
А вот и мы. Находим баги в LLVM 8 с помощью анализатора PVS-Studio: https://habr.com/ru/company/pvs-studio/blog/450008/