The OpenNET Project / Index page

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

Релиз набора компиляторов LLVM 8.0

20.03.2019 22:59

После шести месяцев разработки представлен релиз проекта LLVM 8.0 (Low Level Virtual Machine) - GCC-совместимого инструментария (компиляторы, оптимизаторы и генераторы кода), компилирующего программы в промежуточный биткод RISC-подобных виртуальных инструкций (низкоуровневая виртуальная машина с многоуровневой системой оптимизации). Сгенерированный псевдокод может быть преобразован при помощи JIT-компилятора в машинные инструкции непосредственно в момент выполнения программы.

Из новых возможностей LLVM 8.0 отмечается включение защиты от атак Spectre, поддержка распараллеленной компиляции в ORC JIT, стабилизация компиляции в WebAssembly, добавление в Clang опции для инициализации автоматически распределяемых переменных, улучшение предкомпиляции и поддержка флага /Zc:dllexportInlines в clang-cl, поддержка архитектуры RISC-V в компоновщике lld, расширение средств диагностики.

Улучшения в Clang 8.0:

  • Добавлена возможность инициализации автоматически распределяемых переменных (например, локальных переменных, определённых внутри конструкций). По умолчанию автоматические переменные остаются не инициализированными. Инициализация осуществляется при указании опции "-ftrivial-auto-var-init=pattern" и позволяет избавиться от некоторых форм неопределённого поведения, вызванных заполнением переменных случайными остаточными данными из стека и регистров. Для принудительного отключения инициализации, например, для больших массивов, предусмотрен атрибут "dont_initialize_me";
  • Добавлена поддержка файлов повторного сопоставления данных профилировния (profile-remapping), которые позволяют сопоставить символьные имена и данные профилирования для использования ранее сгенерированных профилей выполнения вместе с другой версией программы с изменёнными таблицами символов (например, после переименования класса);
  • Добавлены новые диагностические опции: "-Wextra-semi-stmt" для выявления лишних ";" и "-Wempty-init-stmt" для выявления пустых блоков инициализации в конструкциях if, switch и for;
  • Помимо ранее добавленной защиты Retpoline в состав включены изменения для блокирования утечек, вызванных спекулятивным выполнением инструкций в современных 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), детектор неопределенного поведения, выявляющий во время выполнения программы ситуации, когда поведение программы становится неопределенным. Расширен спектр ситуаций, охватываемых в режиме "-fsanitize=implicit-conversion" (Implicit Conversion Sanitizer), например, добавлено выявление проблем с составными операторами присваивания и обеспечено определение неявных изменений знака целых чисел ("-fsanitize=implicit-integer-sign-change"). При проверке выравнивания теперь выполняется проверка атрибутов, подобных "assume_aligned";
  • Расширены возможности кеширующего сервера clangd (Clang Server), например, добавлена поддержка глобального для всех файлов проекта индекса, обеспечено добавление спецификаторов пространств имён при автодополнении кода, предложен индекс экспортируемых символов, добавлено расширение LSP;
  • В linter clang-tidy добавлена большая порция новых проверок.

Основные новшества LLVM 8.0:

  • Снят флаг экспериментальной разработки с целевой платформы WebAssembly, поддержка которой теперь включена по умолчанию и не требует указания опции LLVM_EXPERIMENTAL_TARGETS_TO_BUILD. В разряд стабильных также переведены формат объектных файлов и C ABI для платформы WebAssembly. Экспериментальной пока остаётся только поддержка многопоточности в WebAssembly;
  • В утилиту llvm-cov добавлена опция "-format=lcov" для экспорта coverage-статистики в формате lcov;
  • Добавлена опция "-x86-discriminate-memops", использующая отладочную информацию для точной идентификации инструкций x86 с обращающимися к памяти операндами для упреждающей загрузки в кэш (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" обеспечено автодополнение ввода табуляцией;
  • В libc++ прекращена поддержка macOS 10.6 и удалены типы std::dynarray и std::bad_array_length, не вошедшие в стандарт C++;
  • В компоновщике LLD добавлена поддержка архитектуры RISC-V и начальная поддержка ISA MSP430. Добавлены новые флаги: "--call-graph-profile", "--no-call-graph-profile", "--warn-ifunc-textrel", "-z interpose", "-z global", "-z nodefaultlib". При компоновке ELF-файлов сегмент ".note" теперь помещается в первую страницу генерируемого файла для упрощения доступа к важной информации (например .note.gnu.build-id) в core-файлах, даже в случае их усечения по размеру. Добавлена начальная поддержка создания разделяемых библиотек для WebAssembly;
  • В бэкенд для архитектуры x86 добавлена поддержка CPU AMD bdver2 на базе микроархитектуры Piledriver. Для указания в опции "-march" добавлен новый идентификатор CPU "cascadelake", идентичный skylake-avx512 с включением дополнительного набора инструкций avx512vnni. Прекращена подстановка инструкции ADCX, которая мало чем отличается от инструкции ADC, но увеличивает размер кода;
  • Внесены многочисленные улучшения в бэкенды для архитектур AArch64, ARM, SystemZ, Hexagon, MIPS и PowerPC.


  1. Главная ссылка к новости (http://lists.llvm.org/pipermai...)
  2. OpenNews: Проект LLVM ввёл в строй официальное Git-зеркало в ходе миграции с SVN
  3. OpenNews: Релиз набора компиляторов LLVM 7.0
  4. OpenNews: В знак несогласия с новым кодексом поведения LLVM покинул один из ведущих разработчиков
  5. OpenNews: Релиз набора компиляторов LLVM 6.0
  6. OpenNews: Обеспечена возможность сборки ядер Linux 4.4 и 4.9 при помощи Clang
Лицензия: CC-BY
Тип: Программы
Ключевые слова: llvm, clang
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (29) Ajax/Линейный | Раскрыть все сообщения | RSS
 
  • 1.1, гуси (?), 23:04, 20/03/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –6 +/
    Ядро уже им конпелируется?
     
     
  • 2.3, Аноним (3), 23:23, 20/03/2019 [^] [^^] [^^^] [ответить]  
  • +8 +/
    Да, после того как VLA (Variable Length Arrays)  из ядра убрали.
    https://clangbuiltlinux.github.io/
    https://github.com/nathanchance/android-kernel-clang
     
     
  • 3.8, Аноним (8), 09:29, 21/03/2019 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > VLA

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

     
     
  • 4.9, петявася (?), 10:26, 21/03/2019 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Внезапно они есть с C99, плюс в C11 немного поставили.
     
  • 4.12, Аноним (12), 10:51, 21/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Отвратительная штука ибо ты не можешь отследить выделилась память или нет и тупо сваливаешься на переполнении стека
     
     
  • 5.13, Аноним (13), 11:22, 21/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Его это не волнует.
     
     
  • 6.14, Cradle (?), 12:31, 21/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    иногда волнует, но также порой волнует потеря циклов 16-мгц контроллера на выделение и освобождение кучи когда на стеке место гарантировано есть. Так что лучше когда есть выбор.
     
     
  • 7.15, Аноним (13), 12:43, 21/03/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > иногда волнует, но также порой волнует потеря циклов 16-мгц контроллера на выделение
    > и освобождение кучи когда на стеке место гарантировано есть. Так что
    > лучше когда есть выбор.

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

     
  • 7.18, Ordu (ok), 16:20, 21/03/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Если ты статически уверен, что памяти на стеке достаточно, значит ты статически знаешь сколько там есть и сколько тебе надо. То есть ты посчитал максимальный размер того, что тебе надо, и убедился в том, что этот максимальный размер возможно выделить. Ну так выдели максимальный, в чём проблема-то?
    Твоему 16MHz процессору это может даже приятнее будет, поскольку это может уменьшить количество динамической возни с указателем стека.
     
     
  • 8.23, Урри (?), 09:44, 22/03/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А что, в любой программе существует только одна функция с однократным вызовом?

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

     
     
  • 9.26, Cradle (?), 13:01, 22/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    в embedded это еще возможно отследить (и очень желательно), в браузере точно уже нет.
     
  • 9.27, Cradle (?), 13:03, 22/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > с однократным вызовом

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

     
  • 9.29, Ordu (ok), 15:48, 22/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > А что, в любой программе существует только одна функция с однократным вызовом?

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

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

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

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

     
     
  • 10.30, Cradle (?), 16:13, 22/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    да все понятно что тут аргументов больше против чем за и большой риск нарваться, а за использование vla в сразу нескольких вложенных функциях на разных уровнях я бы тоже по рукам бил больно. С другой стороны, вот например MISRA вносит целую кучу запретов, понятных и не очень, а потом люди встречаются и думают: "а если мы в нашей функции alloca используем, станет ругаться или не заметит?"
     
     
  • 11.31, Ordu (ok), 19:19, 22/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    А зачем использовать alloca? Если уж совсем никак не уйти от динамического размера, а куча слишком медленная, то можно же сделать специализированный аллокатор под такого рода вещи.
     
  • 8.25, Cradle (?), 12:57, 22/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну так выдели максимальный

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

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

     
  • 5.16, Аноним (16), 12:44, 21/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Без VLA происходит то же самое.
     
     
  • 6.17, Аноним (16), 12:52, 21/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Другое дело, что если использоется VLA или alloca, особенно внутри if или цикла, то компилятору труднее оптимизировать, ибо Stack Pointer в пределах функции уже не постоянная величина, и надо либо генерить код, которые учитывает изменения Stack Pointer, либо таки использовать регистр под Frame Pointer, а не под что-то более полезное.
     
  • 5.33, adolfus (ok), 11:41, 25/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    На 64-разрядной архитектуре стек и куча используют одно и то же логическое адресное пространство, поэтому без разницы, где вы будете выделять память, в стеке или в куче -- если память исчерпывается, она исчерпывается как для стека, так и для кучи. А выделять локальную память в стеке быстрее и удобнее.
     
  • 4.20, Аноним (20), 18:54, 21/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Вообще да, но для ядра опасненько.
     
  • 3.10, петявася (?), 10:27, 21/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    clang не может в C99 / C11 =)
     
     
  • 4.11, Аноним (11), 10:33, 21/03/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Linux не может в C99 / C11 =)
     
  • 4.21, Аноним (21), 19:46, 21/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Еще как может
     
     
  • 5.22, asdasd (?), 20:16, 21/03/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Тогда почему:
    > Ядро уже им конпелируется?
    >> Да, после того как VLA (Variable Length Arrays)  из ядра убрали.
    >>> VLA
    >>>>Полезная штука, кстати. Жаль, что нет в стандарте ISO C.
     
  • 2.5, Аноним (-), 23:50, 20/03/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    конпелируется, но результат конпеляции гораздо жЫрнее.
     
     
  • 3.32, Ordu (ok), 00:16, 23/03/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не поленился, собрал.

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

     
  • 1.6, Аноним (6), 00:50, 21/03/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Что-то очень мало фич, результат погони за версиями?
     
  • 1.7, Аноним (7), 09:29, 21/03/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Ожидаем, растоманы здеся)
     
  • 1.19, iZEN (ok), 18:47, 21/03/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Для тех, кто желает использовать новый 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

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:


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