The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Релиз набора компиляторов LLVM 8.0"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Релиз набора компиляторов LLVM 8.0"  +/
Сообщение от opennews (?), 20-Мрт-19, 23:04 
После шести месяцев разработки представлен (http://lists.llvm.org/pipermail/llvm-dev/2019-March/131157.html) релиз проекта 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.dev/opennews/art.shtml?num=50360

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по времени | RSS]


1. "Релиз набора компиляторов LLVM 8.0"  –6 +/
Сообщение от гуси (?), 20-Мрт-19, 23:04 
Ядро уже им конпелируется?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

3. "Релиз набора компиляторов LLVM 8.0"  +8 +/
Сообщение от Аноним (3), 20-Мрт-19, 23:23 
Да, после того как VLA (Variable Length Arrays)  из ядра убрали.
https://clangbuiltlinux.github.io/
https://github.com/nathanchance/android-kernel-clang
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

8. "Релиз набора компиляторов LLVM 8.0"  –3 +/
Сообщение от Аноним (8), 21-Мрт-19, 09:29 
> VLA

Полезная штука, кстати. Жаль, что нет в стандарте ISO C.

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

9. "Релиз набора компиляторов LLVM 8.0"  +4 +/
Сообщение от петявася (?), 21-Мрт-19, 10:26 
Внезапно они есть с C99, плюс в C11 немного поставили.
Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

12. "Релиз набора компиляторов LLVM 8.0"  +/
Сообщение от Аноним (12), 21-Мрт-19, 10:51 
Отвратительная штука ибо ты не можешь отследить выделилась память или нет и тупо сваливаешься на переполнении стека
Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

13. "Релиз набора компиляторов LLVM 8.0"  +/
Сообщение от Аноним (13), 21-Мрт-19, 11:22 
Его это не волнует.
Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

14. "Релиз набора компиляторов LLVM 8.0"  +/
Сообщение от Cradle (?), 21-Мрт-19, 12:31 
иногда волнует, но также порой волнует потеря циклов 16-мгц контроллера на выделение и освобождение кучи когда на стеке место гарантировано есть. Так что лучше когда есть выбор.
Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

15. "Релиз набора компиляторов LLVM 8.0"  +2 +/
Сообщение от Аноним (13), 21-Мрт-19, 12:43 
> иногда волнует, но также порой волнует потеря циклов 16-мгц контроллера на выделение
> и освобождение кучи когда на стеке место гарантировано есть. Так что
> лучше когда есть выбор.

Вот и меня волнует. А того не волнует, он ведь "не можешь отследить..."

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

18. "Релиз набора компиляторов LLVM 8.0"  +1 +/
Сообщение от Ordu (ok), 21-Мрт-19, 16:20 
Если ты статически уверен, что памяти на стеке достаточно, значит ты статически знаешь сколько там есть и сколько тебе надо. То есть ты посчитал максимальный размер того, что тебе надо, и убедился в том, что этот максимальный размер возможно выделить. Ну так выдели максимальный, в чём проблема-то?
Твоему 16MHz процессору это может даже приятнее будет, поскольку это может уменьшить количество динамической возни с указателем стека.
Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

23. "Релиз набора компиляторов LLVM 8.0"  +2 +/
Сообщение от Урри (?), 22-Мрт-19, 09:44 
А что, в любой программе существует только одна функция с однократным вызовом?

Блин, а я потом удивляюсь - почему это браузеры жрут всю доступную память?

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

26. "Релиз набора компиляторов LLVM 8.0"  +/
Сообщение от Cradle (?), 22-Мрт-19, 13:01 
в embedded это еще возможно отследить (и очень желательно), в браузере точно уже нет.
Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

27. "Релиз набора компиляторов LLVM 8.0"  +/
Сообщение от Cradle (?), 22-Мрт-19, 13:03 
> с однократным вызовом

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

Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

29. "Релиз набора компиляторов LLVM 8.0"  +/
Сообщение от Ordu (ok), 22-Мрт-19, 15:48 
> А что, в любой программе существует только одна функция с однократным вызовом?

Если у тебя для нескольких функций достаточно памяти на стеке, то ты ведь для них тоже для всех посчитал, сколько каждая из них выделит максимально? И в сумме получилось меньше стека?

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

> Блин, а я потом удивляюсь - почему это браузеры жрут всю доступную
> память?

Да, ещё и ядро тоже. Они тоже отказались от объектов динамических размеров на стеке. Глубина рекурсии у них по жизни должна была просчитываться статически,

Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

30. "Релиз набора компиляторов LLVM 8.0"  +/
Сообщение от Cradle (?), 22-Мрт-19, 16:13 
да все понятно что тут аргументов больше против чем за и большой риск нарваться, а за использование vla в сразу нескольких вложенных функциях на разных уровнях я бы тоже по рукам бил больно. С другой стороны, вот например MISRA вносит целую кучу запретов, понятных и не очень, а потом люди встречаются и думают: "а если мы в нашей функции alloca используем, станет ругаться или не заметит?"
Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

31. "Релиз набора компиляторов LLVM 8.0"  +/
Сообщение от Ordu (ok), 22-Мрт-19, 19:19 
А зачем использовать alloca? Если уж совсем никак не уйти от динамического размера, а куча слишком медленная, то можно же сделать специализированный аллокатор под такого рода вещи.
Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

25. "Релиз набора компиляторов LLVM 8.0"  +/
Сообщение от Cradle (?), 22-Мрт-19, 12:57 
> Ну так выдели максимальный

на самом деле чаще всего так и делаем, хотя не красиво как-то.

Вообще дискуссия не прекращается на эту тему: https://stackoverflow.com/questions/12407754/what-technical-... , http://c-faq.com/malloc/alloca.glb.html

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

16. "Релиз набора компиляторов LLVM 8.0"  +/
Сообщение от Аноним (16), 21-Мрт-19, 12:44 
Без VLA происходит то же самое.
Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

17. "Релиз набора компиляторов LLVM 8.0"  +/
Сообщение от Аноним (16), 21-Мрт-19, 12:52 
Другое дело, что если использоется VLA или alloca, особенно внутри if или цикла, то компилятору труднее оптимизировать, ибо Stack Pointer в пределах функции уже не постоянная величина, и надо либо генерить код, которые учитывает изменения Stack Pointer, либо таки использовать регистр под Frame Pointer, а не под что-то более полезное.
Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

33. "Релиз набора компиляторов LLVM 8.0"  +1 +/
Сообщение от adolfus (ok), 25-Мрт-19, 11:41 
На 64-разрядной архитектуре стек и куча используют одно и то же логическое адресное пространство, поэтому без разницы, где вы будете выделять память, в стеке или в куче -- если память исчерпывается, она исчерпывается как для стека, так и для кучи. А выделять локальную память в стеке быстрее и удобнее.
Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

20. "Релиз набора компиляторов LLVM 8.0"  +/
Сообщение от Аноним (20), 21-Мрт-19, 18:54 
Вообще да, но для ядра опасненько.
Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

10. "Релиз набора компиляторов LLVM 8.0"  +/
Сообщение от петявася (?), 21-Мрт-19, 10:27 
clang не может в C99 / C11 =)
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

11. "Релиз набора компиляторов LLVM 8.0"  +3 +/
Сообщение от Аноним (11), 21-Мрт-19, 10:33 
Linux не может в C99 / C11 =)
Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

21. "Релиз набора компиляторов LLVM 8.0"  +/
Сообщение от Аноним (21), 21-Мрт-19, 19:46 
Еще как может
Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

22. "Релиз набора компиляторов LLVM 8.0"  –1 +/
Сообщение от asdasd (?), 21-Мрт-19, 20:16 
Тогда почему:
> Ядро уже им конпелируется?
>> Да, после того как VLA (Variable Length Arrays)  из ядра убрали.
>>> VLA
>>>>Полезная штука, кстати. Жаль, что нет в стандарте ISO C.
Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

5. "Релиз набора компиляторов LLVM 8.0"  +2 +/
Сообщение от Аноним (-), 20-Мрт-19, 23:50 
конпелируется, но результат конпеляции гораздо жЫрнее.
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

32. "Релиз набора компиляторов LLVM 8.0"  +2 +/
Сообщение от Ordu (ok), 23-Мрт-19, 00:16 
Не поленился, собрал.

$ 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%. Не тянет на "гораздо" ведь, не?

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

6. "Релиз набора компиляторов LLVM 8.0"  –1 +/
Сообщение от Аноним (6), 21-Мрт-19, 00:50 
Что-то очень мало фич, результат погони за версиями?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

7. "Релиз набора компиляторов LLVM 8.0"  –1 +/
Сообщение от Аноним (7), 21-Мрт-19, 09:29 
Ожидаем, растоманы здеся)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

19. "Релиз набора компиляторов LLVM 8.0"  –3 +/
Сообщение от iZENemail (ok), 21-Мрт-19, 18:47 
Для тех, кто желает использовать новый 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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

34. "Релиз набора компиляторов LLVM 8.0"  +/
Сообщение от Andrey_Karpov (ok), 29-Апр-19, 21:42 
А вот и мы. Находим баги в LLVM 8 с помощью анализатора PVS-Studio: https://habr.com/ru/company/pvs-studio/blog/450008/
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру