The OpenNET Project / Index page

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

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

13.03.2017 21:59

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

LLVM 4.0 стал первым выпуском в рамках новой нумерации версий, в которой решено уйти от разделения значительных и функциональных выпусков. Отныне в каждом функциональном обновлении будет меняться первая цифра (в сентябре состоится релиз LLVM 5.0.0, весной следующего года 6.0.0 и т.д.). Для обеспечения совместимости с существующими системами разбора номеров версий LLVM корректирующие обновления, как и раньше будут приводить к увеличению третьей цифры (4.0.1, 4.0.2, 4.0.3).

Из новых возможностей LLVM 4.0 отмечается использование статистики выполнения в оптимизаторе ThinLTO, более агрессивное устранение бесполезного кода, экспериментальная поддержка сопрограмм, экспериментальная поддержка целевой платформы AVR, улучшение совместимости с GNU ld и значительное увеличение производительности компоновщика LLD.

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

  • В оптимизатор ThinLTO ("-flto=thin"), работающий на этапе связывания, добавлена поддержка учёта данных профилирования (PGO, Profile-guided optimization), накопленных в процессе выполнения программы, для более точного принятия решений об импортировании функций и продвижения косвенных вызовов между различными модулями. При включении отладочного режима (-g) существенно сокращено время сборки и уменьшен размер исполняемого файла;
  • Добавлен атрибут diagnose-if, позволяющем выводить предупреждения или ошибки, если вызов функции соответствует одному или нескольким условиям, определённым пользователем. Например:
    
        void abs(int a)
           __attribute__((diagnose_if(a >= 0, "Redundant abs call", "warning")));
    
  • Расширены средства девиртуализации (замена непрямых вызовов на условное выполнение развёрнутых inline-блоков) при помощи новой опции "-fstrict-vtable-pointers";
  • Представлен новый флаг компиляции "-Og", позволяющий выполнить оптимизацию с учётом применения сборки для отладки (в текущей версии опция аналогична применению режима "-O1");
  • Добавлена опция "-MJ" для вывода БД компиляции в формате JSON для интеграции с существующими системами сборки;
  • Устранена порция ошибок в реализации OpenCL и добавлено новое OpenCL-расширение cl_khr_mipmap_image. Добавлен флаг "-cl-ext" для переопределения списка расширений, компилируемых для выбранной целевой платформы. Добавлены "#pragma OPENCL EXTENSION the_new_extension_name : begin/end" для добавления собственных расширений OpenCL без правки кода Clang. В документацию Clang включено руководство по OpenCL;
  • В статическом анализаторе улучшена поддержка кода, использующего gtest. Добавлена опция "--show-description" для вывода описаний дефектов в списке scan-build. Добавлены новые проверки: предупреждение при виртуальных вызовах из конструкторов и деструкторов, проверка синхронизированных копий свойств mutable-типов в Objective C, таких как NSMutableArray, проверка нежелательных сравнений NSNumber, CFNumberRef и других числовых объектов Cocoa со скалярными значениями;
  • В linter clang-tidy добавлена большая порция новых проверок. В include-fixer обеспечена интеграция с Emacs;

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

  • Добавлена экспериментальная поддержка сопрограмм, активируемая при указании опции "-enable-coroutines" или через API addCoroutinePassesToExtensionPoints;
  • В компоновщике LLD значительно улучшена совместимость с GNU linker в плане поддержки формата ELF. LLD доведён до возможности применения для связывания всех файлов при сборке базовой системы и ядра FreeBSD. Значительно увеличена производительности многопоточного режима, который теперь включен по умолчанию. LLD 4.0 примерно в полтора раза быстрее чем LLD 3.9 при выполнении связывания больших программ. Значительные оптимизации также реализованы и при работе с форматом COFF, например, скорость связывания Chromium DLL в окружении Windows возросла в два с половиной раза, по сравнению с прошлым выпуском;
  • Повышены требования к минимальным версиям компиляторов GCC и Visual Studio 2015. Для сборки LLVM теперь необходимы как минимум GCC 4.8 и Visual Studio 2015;
  • Обеспечена обработка invariant.group для различных базовых блоков, что сделало возможным выполнение девиртуализации виртуальных вызовов внутри циклов;
  • В фазе агрессивного удаления мёртвого кода (adce) реализовано удаление веток, не влияющих на поведение программы. Циклы оставляются по умолчанию, но они могут быть удалены при явном указании опции "-adce-remove-loops", если тело цикла не включает значимых операций;
  • В утилиту llvm-cov добавлена возможность экспорта coverage-статистики в формате JSON. Кроме того, также улучшен вывод в формате HTML;
  • Добавлена поддержка соглашения о вызове __regcall, предложенного в компиляторе Intel и нацеленного на максимальное использование регистров для передачи и возвращения значений. Соглашение о вызове __vectorcall, представленное в компиляторах Microsoft, расширено возможностью корректной обработки HVA (Homogeneous Vector Aggregate);
  • Реализована возможность тестирования фаз компиляции, манипулирующих машинными инструкциями, используя формат сериализации MIR (Machine IR). В LLC (LLVM static compiler) добавлена поддержка опций "-run-pass", "-stop-after", "-stop-before", "-start-after" и "-start-before" для запуска только одной выбранной фазы в цепочке генерации кода или для остановки/запуска цепочки генерации кода с заданной позиции;
  • В состав включён бэкенд с поддержкой архитектуры AVR;
  • Для архитектуры x86 добавлена поддержка CPU AMD Ryzen (znver1), обеспечено применения кодирования VEX для CPU с поддержкой AVX-512 для сокращения размера кода, улучшена генерация кода с инструкциями AVX-512;
  • Внесены многочисленные улучшения в бэкенды для архитектур AArch64, ARM, MIPS и PowerPC.


  1. Главная ссылка к новости (http://lists.llvm.org/pipermai...)
  2. OpenNews: Проект LLVM переходит на новую схему нумерации выпусков
  3. OpenNews: Проект LLVM планирует сменить лицензию
  4. OpenNews: Релиз набора компиляторов LLVM 3.9
  5. OpenNews: Новая версия набора компиляторов LLVM 3.8
  6. OpenNews: Администрация по национальной ядерной безопасности США подключилась к усовершенствованию LLVM
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/46181-llvm
Ключевые слова: llvm, clang
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (66) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 22:16, 13/03/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    LLVM — это хорошо. А еще лучше будет, когда со шлангом можно генту собрать, полностью.
     
     
  • 2.6, Crazy Alex (ok), 22:48, 13/03/2017 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Зачем?
     
     
  • 3.9, кельвин (?), 22:55, 13/03/2017 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Зачем?

    Надо!

     
     
  • 4.32, Нанобот (ok), 10:04, 14/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    кому?
     
     
  • 5.66, Аноним (-), 18:03, 21/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Мне
     
  • 2.18, Я. Р. Ош (?), 00:24, 14/03/2017 [^] [^^] [^^^] [ответить]  
  • +9 +/
    Собирай, я разрешаю. Патчи добавишь в апстрим. Потом займись поддержкой сборки icc - поинтереснее будет.
     
     
  • 3.58, Аноним (-), 19:00, 14/03/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    icc и правда интереснее, когда сделаешь?
     
  • 2.22, Аноним (-), 07:04, 14/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > А еще лучше будет, когда со шлангом можно генту собрать, полностью.

    А что конкретно не собирается? Костыли для GCC?

     
     
  • 3.62, anonymous (??), 15:53, 15/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    ядро шлангом не собирается. Оно рассчитано на несовместимое нестандартизированное поведение gcc.
     

  • 1.2, Аноним (-), 22:24, 13/03/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    И каким теперь образом узнать, где поломали API?
     
     
  • 2.3, Аноним (-), 22:28, 13/03/2017 [^] [^^] [^^^] [ответить]  
  • +13 +/
    Раньше API ломали при смене второй цифры, теперь первой :)
     

  • 1.4, Аноним (-), 22:39, 13/03/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    ну сделали нумерацию как у apple сейчас, с учетом того что пилят инженеры эпла молодцом, сделали себе удобно.
     
  • 1.5, Аноним (-), 22:40, 13/03/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    "...Повышены требования к минимальным версиям компиляторов. Для сборки LLVM теперь необходимы как минимум GCC 4.8 ..."

    Ого! а я-то думал он сам себя умеет собирать...

     
     
  • 2.7, кельвин (?), 22:53, 13/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    умеет.. clang 3.1 собирает.
     
  • 2.8, angra (ok), 22:55, 13/03/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Умеет. Даже кросскомпиляцию самого себя умеет. Но в большинстве случаев для бутстрапа используется gcc.
     
  • 2.17, Сифилис (?), 23:45, 13/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    на macOS и *BSD не нужен gcc, для линукса жизненно необходимо как и часть системы.
     
     
  • 3.23, Аноним (-), 07:05, 14/03/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > жизненно необходимо как
    > и часть системы.

    Вы что-то путаете, гражданчик. GCC только для ядра нужен, из-за его (GCC) специфичных костылей.

     
     
  • 4.29, qqq (??), 09:16, 14/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    да ты что? для начала глянь, сколько софта у тебя с libstdc++ слинковано, а потом уже чушь про "только для ядра" неси
     
     
  • 5.30, Анончик (?), 09:38, 14/03/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > да ты что? для начала глянь, сколько софта у тебя с libstdc++
    > слинковано, а потом уже чушь про "только для ядра" неси

    При чём тут libstdc++? Это стандартная крестовая либа, да, она поставляется и собирается вместе с GCC, но у LLVM тоже есть libc++, на которую вполне успешно переползла фряха и которую вроде как юзает макось.
    Но это всё лирика, суть же в том, что GCC умеет в GNU-специфичные расширения и инструкции, которые не являются частью стандарта языка, плюс для определённых конструкций GCC генерирует определённый ассемблерный код. И вот на эти особенности компиляции и гнутые расширения и завязана часть экосистемы линукса, в том числе ядро, иксы, часть иксодров, glibc и т.п..

     
     
  • 6.43, qqq (??), 13:51, 14/03/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    вот когда во всех дистрибутивах все и вся будет собирано шлангом, тогда и можно будет говорить про "только ядро". а пока-что рановато
     
     
  • 7.64, Мойша (??), 13:34, 30/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, пол года назад на генте не удалось скомпилировать clang'ом только ядро, глибцы и какие-то сетевые библиотеки, а также poppler(целью было скомпилировать полностью укомплектованную плазму со всеми kde-applications). Сейчас возможно даже лучше стало.
     
  • 5.59, Сифилис (?), 20:17, 14/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    В libcxx++ не нужен libstdc++
     
     
  • 6.61, Аноним (-), 08:53, 15/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > В libcxx++ не нужен libstdc++

    xx++ - это уже четырежды плюс! Новый язык?

     

  • 1.10, Аноним (10), 22:55, 13/03/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –16 +/
    зачем этот шланг нужен вообще? Ресурсы процессора девать наверное сейчас некуда, мало жирных и тормозных описаний абстракций c++, так нужно ещё такты процессора забивать ненужной прослойкой эмулятора виртуального кода.
     
     
  • 2.11, Аноним (-), 23:05, 13/03/2017 [^] [^^] [^^^] [ответить]  
  • +7 +/
    >зачем этот шланг нужен вообще? Ресурсы процессора девать наверное сейчас некуда, мало жирных и тормозных описаний абстракций c++, так нужно ещё такты процессора забивать ненужной прослойкой эмулятора виртуального кода.

    Какая-такая "прослойка", какие такты, какой эмулятор? То, что вы описываете - это какой-то корявых интерпретатор. Даже в версии JIT нет никаких "эмуляторов", байт-код компилируется в момент запуска и после этого является самым обыкновенным нативным кодом. Не нравится JIT, можно откомпилировать сразу нативный бинарник, такой же самый, как сделает GCC.

     
  • 2.19, leap42 (ok), 02:13, 14/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >> жирных и тормозных описаний абстракций c++

    ахахах - а в каких языках нежирные тогда - python? java?

     
     
  • 3.24, Аноним (-), 07:06, 14/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >>> жирных и тормозных описаний абстракций c++
    > ахахах - а в каких языках нежирные тогда - python? java?

    Pure C, Lua?

     
     
  • 4.26, Ordu (ok), 08:23, 14/03/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Pure C

    Ты знаешь современный компилятор Pure C, который не использует промежуточного кода для компиляции и при этом не только под x86 умеет генерить код?

     
     
  • 5.63, жопка3 (?), 22:59, 16/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Лучше не так, лучше спросить знает ли он компилятор Pure C(что это такое - не понятно), написанный не на C++ :)
     

  • 1.12, Штунц (?), 23:09, 13/03/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Кто может объяснить, какой плюс от преобразования в машинные инструкции непосредственно в момент запуска? И так каждый раз, в каждый момент запуска. Зачем?
     
     
  • 2.13, Аноним (-), 23:22, 13/03/2017 [^] [^^] [^^^] [ответить]  
  • +11 +/
    > Кто может объяснить, какой плюс от преобразования в машинные инструкции непосредственно
    > в момент запуска? И так каждый раз, в каждый момент запуска.
    > Зачем?

    Прежде всего - есть опция компилировать сразу в машинный код. Преимуществом jit является по большому счету портируемость и всяческие оптимизации. Если есть сферический компилятор С(++), то он откомпилирует программу под конкретную архитектуру и даже под конкретную ее версию. Например, под i386. Этот код не запустится под ARM и не сможет использовать какие-то наборы инструкций, например, MMX, которые появились позже i386, но которые возможно имеются на компьютере пользователя. JIT, теоретически, может обеспечить подобное (не надо мне рассказывать, что написание кросс-платформенного кода сложнее hello world'a - это нетривиальная задача, я в курсе). Помимо этого JIT-компиляторы имеют множество метрик и профилировщиков, которые могут каким-то образом оптимизировать результат в зависимости от определенных условий.
    В случае LLVM это еще и множество бэкэндов, т.е. список аппаратных архитектур, в которые можно транслировать байт-код. То есть, есть 2 независимых процесса -- генерация байт-кода из языка программирования и генерация нативного кода из байт-кода. И поскольку байт-код универсальный, это дает возможность создать комбинацию компилятора языка и архитектуры, для которой классического компилятора не существует.

     
     
  • 3.15, O01eg (?), 23:39, 13/03/2017 [^] [^^] [^^^] [ответить]  
  • –3 +/
    В случае LLVM байт-код не универсальный. Это не аналог JVM и CLR (хотя жаль).
     
     
  • 4.16, Аноним (-), 23:41, 13/03/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >>В случае LLVM байт-код не универсальный. Это не аналог JVM и CLR (хотя жаль).

    Например?

     
  • 4.45, Аноним (-), 14:27, 14/03/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Байткод LLVM как язык - кроссплатформенный. Байткод конкретных приложений, генерируемый Clang'ом - нет. Проблема тут в том, что код на C неизбежно привязывается к целевой платформе после того, как проходит стадию препроцессинга. И уже этот некроссплатформенный после-C компилируется в байткод.
     
  • 3.20, anonymous (??), 04:13, 14/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Т.е. очень хорошо нацелен на решение задачи

      "как бы пошире распространять бинарники, не отдавая исходники"

     
     
  • 4.21, Вареник (?), 06:05, 14/03/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Проприетарщина живет на паре-тройке аппаратных платформ, ей хватает. Плюс мобильники, но там вполне без шланга решены вопросы распространения.
     
  • 4.25, Аноним (-), 08:02, 14/03/2017 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Открою сейчас тайну - большинство пользователей Linux получают софт с открытыми ... большой текст свёрнут, показать
     
     
  • 5.33, Аноним (-), 10:37, 14/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Write Once, Run Everywhere!
     
  • 5.35, Аноним (-), 10:46, 14/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Все хорошо, заисключением одного момента - времени старта приложения
     
     
  • 6.36, Аноним (-), 11:04, 14/03/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Да, тут нужно найти баланс, взвесить за и против Для сложного приложения, котор... большой текст свёрнут, показать
     
     
  • 7.38, Аномсис (?), 11:40, 14/03/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Не забывайте, что биткод(или байткод) в память загрузится полностью и будет отъедать её.
    Плюс скомпилированные куски кода, что в сумме приведёт к большему потреблению памяти.
    Ну и плюс ко всему этому -- память будет потреблять ещё виртуальная машина, которая будет осуществлять JIT компиляцию.
     
     
  • 8.40, Аноним (-), 12:16, 14/03/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Я могу ошибаться по поводу LLVM, но нет никакой необходимости грузить в память в... текст свёрнут, показать
     
     
  • 9.41, Аномсис (?), 12:33, 14/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Возможно вы правы Я тоже не знаю полностью они грузятся или частями по мере нео... текст свёрнут, показать
     
  • 7.44, Аноним (-), 14:08, 14/03/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Я думал, нативный бинарник сначала ммапится в память по определённым смещениям, и лишь потом загружается в память физически постранично по мере надобности. Неиспользуемые страницы, если что, могут быть "сброшены" обратно на диск.

    Может, вопрос больше в занимании памяти на диске этим разросшимся бинарником?

     
  • 6.39, PnDx (ok), 11:57, 14/03/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Оформить уже́ "докомпиляцию" (транслятор в инструкции местного CPU, назовите лучше) в post-install пакета. Профит (для ≈10% софта, где есть чего ловить). Неужели ещё не докумекали до такого варианта?
    Сейчас для этого лепят 100500 precompiled вариантов (где совсем-совсем надо).
     
     
  • 7.52, Вареник (?), 15:14, 14/03/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Оформить уже́ "докомпиляцию" (транслятор в инструкции местного CPU, назовите лучше)
    > в post-install пакета. Профит (для ≈10% софта, где есть чего ловить).
    > Неужели ещё не докумекали до такого варианта?
    > Сейчас для этого лепят 100500 precompiled вариантов (где совсем-совсем надо).

    АОТ. В Андроиде внедрили, в основной Жабе пытаются внедрить.
    LLVM позволяет (пока реально в пакетах никто не пользуется, как и JIT).

     
  • 6.51, Вареник (?), 15:12, 14/03/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Все хорошо, заисключением одного момента - времени старта приложения

    Можно сделать по типу АОТ - только один раз при инсталляции на конкретную архитектуру.
    В этом смысле LLVM весьма гибкий.

     
  • 6.54, freehck (ok), 16:13, 14/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Все хорошо, заисключением одного момента - времени старта приложения

    А разве LLVM сразу после окончания выполнения программы теряет уже скомпилированный нативный код? Насколько я помню описание LLVM, вроде ж сохранять должен.

    Дисклеймер: LLVM не пользуюсь, только читал.

     
  • 5.37, Аномсис (?), 11:23, 14/03/2017 [^] [^^] [^^^] [ответить]  
  • +3 +/
    JIT хуже оптимизирует, т.к. работает в реальном времени и должен производить оптимизацию  быстро.
    Но с LLVM можно полученный биткод запустить не только через JIT, а полноценно скомпилировать под свою архитектуру.
    При этом скорость компиляции должна быть намного быстрее, чем непосредственно из исходников, т.к. архитектурно-независимая оптимизация уже была проведена на этапе преобразования в биткод. И остаётся только архитектурно-зависимая оптимизация.

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

     
     
  • 6.47, Аноним (-), 14:42, 14/03/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > JIT хуже оптимизирует, т.к. работает в реальном времени и должен производить оптимизацию
    >  быстро.

    Зависит от уровня абстракции байткода от нативного. В принципе, самые «жирные» оптимизации как раз делаются еще до или при преобразовании в байт-код.
    Да и не нужно валивать все в кучу и сравнивать с JIТами JaбкоСкрипта, Луа, Питона и т.д., где JITу действительно нужно в реальном времени скомпилировать «от и до».

     
  • 6.57, Crazy Alex (ok), 16:55, 14/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    всё так, только про генту не надо - она вообще не о том
     
  • 5.53, zfs (??), 15:42, 14/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > выхлоп традиционного компилятора - это неизменный монолит

    Верно, но с небольшим уточнением. Многие С++ либы, в частности, криптогроафические пользуются такой фичей: https://gcc.gnu.org/wiki/FunctionMultiVersioning

     
  • 5.55, freehck (ok), 16:29, 14/03/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Открою сейчас тайну - большинство пользователей Linux получают софт с открытыми исходниками
    > в виде бинарников, кроме случаев типа Gentoo, которые как раз меньшинство.
    > И когда собирают пакет, то его компилируют очень осторожно, образно говоря,
    > чтобы он запустился и на 6 летнем Core2 Duo, и на
    > свежем i7. Ни обладатели i7, ни обладатели свеженького AMD Ryzen ничего
    > из их новых наборов команд использовать не смогут, т.к. выхлоп традиционного
    > компилятора - это неизменный монолит, а вот JIT тут мог бы
    > быть полезен.

    Ну, в большинстве случаев AOT не является проблемой для пользователя. Чесслово, у меня i7 с 8ю потоками выполнения: я не сильно страдаю от того, что некоторые программы выполняются неоптимально. Критичные долгоработающие демоны можно и перекомпилировать, если что. Тут делов как бы не много: apt-get source, поправить флаги и pbuilder натравить. Но это, опять же, в исключительных случаях.

    JIT, хоть и является весьма старой технологией, стал модным трендом относительно недавно.
    В принципе, промежуточное представление компилируемой программы в байткоде есть и в GCC. Даже, если память не изменяет, их целых два: Generic и Gimple. После второго за дело берутся бэкенды, производящие компиляцию уже в конечную архитектуру.

    В общем, идеи-то старые. Если бы они были действительно востребованы, в GCC их бы реализовали уже давно. Однако на деле, влияние JIT-а не сильно сказывается на работе.

    Популярность LLVM во многом обусловлена пермиссивной лицензией. Именно поэтому корпорации активно вбухивают деньги в проекты для него.

    > Преимущества LLVM лежат больше в плоскости многообразия архитектур и языков программирования

    Поподробнее можно?

     
  • 5.56, Crazy Alex (ok), 16:53, 14/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Для этого AOT нужен, а не JIT. То есть оконяательная стадия компиляции на целевой машине - да, компиляция при каждом запуске - нет.
     
  • 2.14, fail_ (?), 23:33, 13/03/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    оптимизaция по sizeof(L!, L@, L#), хотя бы ?!
     
  • 2.48, adolfus (ok), 14:47, 14/03/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Никакого нет. Даже наоборот. Оптимизация на уровне абстрактной RISC-машины не исключает необходимости оптимизации для конкретной архитектуры, поскольку реальные архитектуры отличаются друг от друга более, чем существенно.
    Парадигма LLVM позволяет быстро начать производить код для новых архитектур -- для этого достаточно написать эмулятор абстрактного RISC-процессора LLVM. Плюс здесь только один -- гибкость, а все остальное в минусах по самое горло. И среди этих минусов два очень важных -- время компиляции и качество оптимизации. С учетом того, что в процессе развития СВТ как памяти, так и производительности все более и более не хватает, с практической точки зрения парадигму LLVM нельзя считать хорошей.

     

  • 1.27, Ноне (?), 08:54, 14/03/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +17 +/
    >более агрессивное устранение бесполезного кода

    Собираешь программу, а бинарник получаетя нулевого размера, и понимаешь что-то в этой жизни пошло не так :)

     
     
  • 2.28, qsdg (ok), 09:06, 14/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Не тем занимаешься в жизни, похоже.
     
  • 2.31, GlorySmith (?), 09:39, 14/03/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >>более агрессивное устранение бесполезного кода
    > Собираешь программу, а бинарник получаетя нулевого размера, и понимаешь что-то в этой
    > жизни пошло не так :)

    Так это же будет идеальная программа - ни одной ошибки!


     
  • 2.34, Аноним (-), 10:46, 14/03/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ваш код был рассмотрен, проверен и вынесен вердикт - идите на курсы программирования в <здесь название школы, куда проприетарастский компилятор вас посылает оглядываясь на то какая школа заплатила за рекламу в вашем регионе>.
     
     
  • 3.49, Вареник (?), 15:06, 14/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    - Где у меня ошибка?
    - В ДНК...
     
  • 2.60, Kodir (ok), 20:43, 14/03/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    SystemD бы так собирать! :)
     

  • 1.42, Аноним (-), 13:25, 14/03/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    репы 3,9 4,0 5,0 для деба\\бунты

    http://apt.llvm.org/

     
  • 1.46, Аноним (-), 14:37, 14/03/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    инвесторы любят большие числа, да.

     
     
  • 2.50, Вареник (?), 15:06, 14/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > инвесторы любят большие числа, да.

    - График роста версий, уходящий в небеса.

     

  • 1.65, iZEN (ok), 09:53, 03/04/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    LLVM 4.0 включен в базовую систему FreeBSD 11-STABLE.
     
     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



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

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