The OpenNET Project / Index page

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

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

26.03.2020 10:25

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

Из новых возможностей LLVM 10.0 отмечается поддержка концепций C++ (C++ Concepts), прекращение запуска Clang в форме отдельного процесса, поддержка проверок CFG (control flow guard) для Windows и поддержка новых возможностей CPU.

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

  • Добавлена поддержка "концепции", расширения шаблонов C++, которое вошло в состав стандарта C++20 (включается флагом -std=c++2a). Концепции позволяют определить набор требований к параметрам шаблона, которые во время компиляции ограничивают набор аргументов, которые могут приниматься в качестве параметров шаблона. Концепции можно применять для того, чтобы избежать логических несоответствий между свойствами типов данных, используемых внутри шаблона, и свойствами типов данных входных параметров.
    
       template<typename T>
       concept EqualityComparable = requires(T a, T b) {
           { a == b } -> std::boolean;
           { a != b } -> std::boolean;
       };
    
  • По умолчанию прекращён запуск отдельного процесса ("clang -cc1"), в котором выполняется компиляция. Компиляция теперь выполняется в основном процессе, а для восстановления старого поведения можно использовать опцию "-fno-integrated-cc1".
  • Новые режимы диагностики:
    • "-Wc99-designator" и "-Wreorder-init-list" - предупреждают об использовании инициализаторов C99 в режиме C++ в случаях, когда они корректны в C99, но не подходят для C++20.
    • "-Wsizeof-array-div" - отлавливает такие ситуации, как "int arr[10]; ...sizeof(arr) / sizeof(short)..." (должно быть "sizeof(arr) / sizeof(int)").
    • "-Wxor-used-as-po" - предупреждает об использовании таких конструкций, как применение оператора "^" (xor) в операциях, которые можно спутать с возведением в степень (2 ^ 16).
    • "-Wfinal-dtor-non-final-class" - предупреждает о классах, не помеченных спецификатором "final", но имеющих деструктор c признаком "final".
    • "-Wtautological-bitwise-compare" - группа предупреждений для диагностики тавтологического сравнения битовой операции и константы, а также для выявления всегда истинных сравнений, в которых битовая операция OR применяется к неотрицательному числу.
    • "-Wbitwise-conditional-parentheses" предупреждает о проблемах при смешивании логических операторов AND ("&") и OR ("|") c условным оператором ("?:").
    • "-Wmisleading-indentation" - аналог одноимённой проверки из GCC, предупреждающей о выражениях, выделенных отступом, будто они входят в блок if/else/for/while, но на самом деле в данный блок не входящих.
    • При указании "-Wextra" обеспечено включение проверки "-Wdeprecated-copy", предупреждающей об использовании конструкторов "move" и "copy" в классах с явным определением деструктора.
    • Расширены проверки "-Wtautological-overlap-compare", "-Wsizeof-pointer-div", "-Wtautological-compare", "-Wrange-loop-analysis".
    • Отключены по умолчанию проверки "-Wbitwise-op-parentheses" и "-Wlogical-op-parentheses".
  • В коде на С и С++ арифметические операции с указателями разрешены только в массивах. Детектор неопределённого поведения (Undefined Behavior Sanitizer) в режиме "-fsanitize=pointer-overflow" теперь отлавливает такие случаи, как добавление ненулевого смещения к указателю со значением null или образование нулевого указателя при вычитании целого числа из ненулевого указателя.
  • Режим "-fsanitize=implicit-conversion" (Implicit Conversion Sanitizer) адаптирован для выявления проблем с операциями инкремента и декремента для типов с битовым размером меньшим, чем у типа "int".
  • При выборе целевых x86-архитектур "-march=skylake-avx512", "-march=icelake-client", "-march=icelake-server", "-march=cascadelake" и "-march=cooperlake" по умолчанию в векторизированном коде прекращено использование 512-разрядных регистров zmm, за исключением их прямого указания в исходных текстах. Причиной является снижение частоты CPU при выполнении 512-разрядных операций, что может негативно сказываться на общей производительности. Для изменения нового поведения предусмотрена опция "-mprefer-vector-width=512".
  • Поведение флага "-flax-vector-conversions" приближено к GCC: запрещены неявные векторные битовые преобразования между целочисленными векторами и векторами с плавающей точкой. Для исключения данного ограничения предлагается использовать флаг "-flax-vector-conversions=all", который используется по умолчанию.
  • Улучшена поддержка CPU MIPS семейства Octeon. В список допустимых типов CPU добавлен "octeon+".
  • При сборке в промежуточный код WebAssembly обеспечен автоматический вызов оптимизатора wasm-opt, при его наличии в системе.
  • Для систем на базе архитектуры RISC-V в условных блоках ассемблерных inline-вставок разрешено использование регистров, хранящих значения с плавающей запятой.
  • Добавлены новые флаги компилятора: "-fgnuc-version" для задания значения версии для "__GNUC__" и подобных макросов; "-fmacro-prefix-map=OLD=NEW" для замены префикса каталогов OLD на NEW в таких макросах, как "__FILE__"; "-fpatchable-function-entry=N[,M]" для генерации определённого числа инструкций NOP перед и после точкой входа в функцию. Для RISC-V добавлена поддержка флагов "-ffixed-xX", "-mcmodel=medany" и "-mcmodel=medlow".
  • Добавлена поддержка атрибута '__attribute__((target("branch-protection=...")))', действие которого аналогично опции -mbranch-protection.
  • На платформе Windows при указании флага "-cfguard" реализована подстановка проверок целостности потока выполнения (Control Flow Guard) при непрямых вызовах функций. Для отключения подстановки проверок можно использовать флаг "-cfguard-nochecks" или модификатор "__declspec(guard(nocf))".
  • Поведение атрибута gnu_inline приближено к GCC, в случаях, когда он используется без ключевого слова "extern".
  • Расширены возможности, связанные с поддержкой OpenCL и CUDA. Добавлена поддержка новых возможностей OpenMP 5.0.
  • В утилиту clang-format добавлена опция Standard, позволяющая определить версию стандарта C++, применяемую при разборе и форматировании кода (Latest, Auto, c++03, c++11, c++14, c++17, c++20).
  • В статический анализатор добавлены новые проверки: alpha.cplusplus.PlacementNew для определения достаточного места в хранилище, fuchsia.HandleChecker для выявления утечек, связанных с обработчиками Fuchsia, security.insecureAPI.decodeValueOfObjCType для определения потенциальных переполнений буфера при использовании [NSCoder decodeValueOfObjCType:at:].
  • В детекторе неопределённого поведения (UBSan, Undefined Behavior Sanitizer) расширены проверки переполнения указателей, которые теперь отлавливают применение ненулевых смещений к указателям NULL или получение в результате добавления смещения указателя со значением NULL.
  • В linter clang-tidy добавлена большая порция новых проверок.



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

  • Во фреймворк Attributor добавлены новые межпроцедурные оптимизации и анализаторы. Обеспечено прогнозирование состояния 19 различных атрибутов, включая 12 атрибутов 12 LLVM IR и 7 абстрактных атрибутов, таких как живучесть (liveness).
  • Добавлены новые встроенные в компилятор матричные математические функции (Intrinsics), которые при компиляции заменяются на эффективные векторные инструкции.
  • Внесены многочисленные улучшения в бэкенды для архитектур X86, AArch64, ARM, SystemZ, MIPS, AMDGPU и PowerPC. Добавлена поддержка CPU Cortex-A65, Cortex-A65AE, Neoverse E1 и Neoverse N1. Для ARMv8.1-M оптимизирован процесс генерации кода (например, появилась поддержка циклов с минимальными накладными расходами) и добавлена поддержка автовекторизации с использованием расширения MVE. Улучшена поддержка CPU MIPS Octeon. Для PowerPC включена векторизация математических подпрограмм с использованием библиотеки MASSV (Mathematical Acceleration SubSystem), улучшена генерация кода и оптимизирован доступ к памяти из циклов. Для x86 изменена обработка векторных типов v2i32, v4i16, v2i16, v8i8, v4i8 и v2i8.
  • Улучшен генератор кода для WebAssembly. Добавлена поддержка TLS (Thread-Local Storage) и инструкции atomic.fence. Значительно расширена поддержка SIMD. В объектных файлах WebAssembly добавлена возможность использования сигнатур функций с несколькими значениями.
  • При обработке циклов задействован анализатор MemorySSA, позволяющий определять зависимости между различными операциями с памятью. MemorySSA позволяет добиться сокращения времени компиляции и выполнения кода или может использоваться вместо AliasSetTracker без потери в производительности.
  • В отладчике LLDB значительно улучшена поддержка формата DWARF v5. Улучшена поддержка сборки с MinGW и добавлена начальная возможность отладки исполняемых файлов Windows для архитектур ARM и ARM64. Добавлены описания опций, предлагаемых при автодополнении ввода нажатием табуляции.
  • Расширены возможности компоновщика LLD. Улучшена поддержка формата ELF, в том числе обеспечена полная совместимость glob-шаблонов с компоновщиком GNU, добавлена поддержка сжатых отладочных секций ".zdebug", добавлено свойство PT_GNU_PROPERTY для определения секции .note.gnu.property (может использоваться в будущих ядрах Linux), реализованы режимы "-z noseparate-code", "-z separate-code" и "-z separate-loadable-segments". Улучшена поддержка MinGW и WebAssembly.


  1. Главная ссылка к новости (http://lists.llvm.org/pipermai...)
  2. OpenNews: Релиз набора компиляторов LLVM 9.0
  3. OpenNews: Разработчики из Google предложили разработать свою libc для LLVM
  4. OpenNews: В знак несогласия с новым кодексом поведения LLVM покинул один из ведущих разработчиков
  5. OpenNews: Экспериментальная поддержка пересборки ядра Linux в Clang с механизмом защиты CFI
  6. OpenNews: Релиз набора компиляторов GCC 9
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/52611-llvm
Ключевые слова: llvm, gcc, compile
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (61) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
 
  • 2.3, Корец (?), 10:54, 26/03/2020 [ответить]  
  • +1 +/
    Фрактал, ты снова тут набрасываешь? У каждого своё понятие свободы :) Зато благодаря наличию разных лицнзий есть выбор. Это плохо?
     
     
  • 3.9, Аноним (9), 11:08, 26/03/2020 [^] [^^] [^^^] [ответить]  
  • +8 +/
    >У каждого своё понятие свободы :)

    Работники министерств правды и любви с вами не согласны.

     
  • 3.23, Lorik (?), 12:39, 26/03/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Это не тот фрактал, который некоторое время назад на лоре чудил?
     
     
  • 4.26, Корец (?), 13:06, 26/03/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А разве есть другой? Его оттуда выгнали, теперь тут чудит.
     
     
  • 5.28, Аноним (-), 13:16, 26/03/2020 Скрыто ботом-модератором     [к модератору]
  • –3 +/
     
  • 5.53, Аноним (53), 17:35, 26/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Не выгнали, а сам ушёл. Причину так и не узнали.
     
  • 2.17, user90 (?), 12:14, 26/03/2020 [ответить]  
  • +2 +/
    Я начинаю подозревать, что ты и есть тот самый школотрон на каникулах ;)
     
     
  • 3.51, Аноним (51), 16:54, 26/03/2020 [^] [^^] [^^^] [ответить]  
  • –5 +/
    А, не всё ли равно - если дело говорит В ч н Исходники GCC - когда смотрел... большой текст свёрнут, показать
     
     
  • 4.52, user90 (?), 17:03, 26/03/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > котрый даже в РФ не иммеет полноценну силу

    Ну дык это же РФ, ггг! Тут ни-че-го не имеет "полноценной силы".

    > Т.е.он так витиевато многосмысленно составлен что это просто

    что ты просто не въехал, ну да не переживай, тебе скорее всего и не нужно.

    По поводу остальной простыни.. на каком-то "жутко-мыльно-русском" написано))

     
     
  • 5.81, Аноним (81), 09:18, 30/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    GPL-фанатик? Бывает...

    > > котрый даже в РФ не иммеет полноценну силу
    > Ну дык это же РФ, ггг!

    «ггг»-идиотам сообщаю:
    - Так я тоже не с РФ, как бы. Такие проблемы везде у нас.
    (Уверен и в НАТО, если не сейчас - то скоро будут; максимум - как введут закономерно ожидаемую сертификацию - всего выпускаемого ПО; и вообще удивляюсь что там до сих пор не прикрыли это - налоги не платят же в общак/казну... и даже конкурентам мешают платить полностью! не говоря уже про упущенную прибыль компаниями - т.к.те сами засадить выписав многомилилардный штраф Столману прям стесняются, будучи такими как вы «ггг»-шникам в обществе просто затерроризированны).

     
  • 4.59, Аноним (59), 18:30, 26/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Выдыхай!
     
     
  • 5.62, Аноним (62), 18:57, 26/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Сам выдыхни, раз нечего возразить.
     
  • 1.4, Аноним (4), 10:56, 26/03/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –19 +/
    То есть для того, чтобы запустить некую программу, скомпилированную с помощью llvm, мне надо на целевой хост поставить, мнэ, интерпретатор llvm, выполняющий "скомпилированный" код.

    Наверное в этом есть какой-то смысл, но я не понимаю.

     
     
  • 2.11, konrad (??), 11:46, 26/03/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    LLVM вроде умеет не только JIT, но и AOT :) а насчёт «какой-то смысл» — он как у Явы: один раз собрал и везде запускаешь (: но я тоже считаю что это не так-то уж и круто, как некоторые думают: собрать четыре релизных билда (линь/винда/мак на х86 и линь на арм) не так уж и сложно, в отличии от создания/развития «универсальной» среды, которая везде должна предоставлять одинаковый функционал ИМХО
     
     
  • 3.21, фывфыв (?), 12:23, 26/03/2020 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Только вот в случае с llvm не работает "один раз собрал" их "язык ассемблера" не такой уж и универсальный (иначе в противном случае любой компилятор на llvm работал бы на всех архитектурах, которые поддерживает llvm, а этого не происходит).
     
  • 3.34, Аноним (4), 13:58, 26/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Я понимаю, что это такая ява с преферансом и куртизанками.

    Я о другом. Конпелятор делает исполняемый файл под целевую платформу, и (1) на этой платформе не нужно никаких прослоек, всё собрано, (2) конпелятор  оптимизирует, чтобы получить максимально быстрый и эффективный код.

    Так вот, в чём смысл механизма llvm с этой точки зрения? Эффективности не получается, дополнительный слой какой-то... Но как бы конпелятор.

     
     
  • 4.44, КО (?), 15:29, 26/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Нет это такой P-код. :)
    Промежуточное представление между тем, упрощает написание компилятора под платформы.
     
     
  • 5.63, Аноним (63), 19:06, 26/03/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Упрощает написание под платформы, значительно усложняя оптимизацию вообще и т.б.под конкретную.
    (Неявно это NIX-way, типично-лаговый:( Пока невыпилят такое поведение компилятора [и мультиплатформенность] - Линуксы всегда будут позади всех в тестах производительноти,
    только из-за этого одного. Хоть мультиплатформенная поддержка - сама по себе требует затрат времни программистов - нелинено, даже просто на поддержание её при каждом чихе в другой платформе, т.о. нелинено уменьшая число даже просто общих оптимизаций и аналогично нужных нововведений синтаксиса, как и аналогично в полноценном документировании).
     
     
  • 6.76, Урри (?), 13:28, 27/03/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    забавно. "позади всех в тестах производительность", но при этом 100% суперкомпьютеров бегают на этой жутко тормозной фигне.

    мне кажется, кто то тут врет. и это точно не суперкомпьютеры.

     
     
  • 7.82, Аноним (82), 09:20, 30/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    вариант: кто то тут врет - и это не я...
     
  • 2.16, Коломойский (?), 12:07, 26/03/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    толи аноним толи чукча
     
  • 2.18, ant2 (?), 12:19, 26/03/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Нет, для пользователя это просто компилятор с/с++ (или другого языка). Особенность проекта в том, что он двуслойный, т.е. он переводит язык в универсальный байт-код low-level virtual machine, а затем этот байт-код переводит в инструкции конкретной платформы (например, amd64).
    Идея в том, что можно сделать универсальные оптимизаторы байт-кода и оптимизаторы перевода байт-кода в код платформы. Поскольку они работают с байт-кодом, то им всё равно откуда этот байт-код взялся. Поэтому, вместо того чтобы мучить полный компилятор для нового языка, достаточно написать frontend, переводящий в байт-код.
    JIT здесь притом, что можно не делать последний шаг при компиляции - перевод в код платформы, а оставить его на потом.
     
     
  • 3.22, user90 (?), 12:32, 26/03/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Этой "особенности" сто лет в обед))
     
     
  • 4.35, kai3341 (ok), 14:01, 26/03/2020 [^] [^^] [^^^] [ответить]  
  • –3 +/
    >  Этой "особенности" сто лет в обед))

    Вы путаете объектный код с LLVM IR

     
     
  • 5.49, meantraitor (?), 16:30, 26/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    "Поэтому, вместо того чтобы мучить полный компилятор для нового языка, достаточно написать
    frontend, переводящий в байт-код."

    Вот этой "особенности" сто лет. IR есть у (практически) любого компилятора.

     
  • 5.57, Брат Анон (?), 17:49, 26/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Это ты анон путаешь.
    Такой подход был реализован в Обороне -- Ява к этому моменту ещё не существовала.
     
  • 5.70, Ordu (ok), 20:54, 26/03/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Нет, это ты путаешь объектный код с IR. IR есть и в gcc тоже, это естественный ход для компилятора, который под несколько платформ компилирует: это позволяет некоторые оптимизации кода проводить кроссплатформенно.
     
  • 3.24, Аноним (24), 12:44, 26/03/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это не особенность, а обыденность.
     
  • 3.32, microsoft (?), 13:32, 26/03/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Да, только фронтенд прийдется писать на богопротивном с++ вместо богоугодного чистого как слеза девственницы анси с.
     
     
  • 4.39, Аноним (59), 14:09, 26/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Сейчас и GCC постепенно переходит на написание самого себя на C++.
     
     
  • 5.43, microsoft (?), 14:39, 26/03/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Пруфы в студию, тоесть часть компилера с написана на плюсах?
     
     
  • 6.45, Аноним84701 (ok), 15:47, 26/03/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Пруфы в студию, тоесть часть компилера с написана на плюсах?

    https://github.com/gcc-mirror/gcc/blob/master/gcc/gimple-loop-interchange.cc#L



    loop_cand::loop_cand (class loop *loop, class loop *outer)
      : m_loop (loop), m_outer (outer), m_exit (single_exit (loop)),
        m_bbs (get_loop_body (loop)), m_num_stmts (0), m_const_init_reduc (0)
    {
        m_inductions.create (3);
        m_reductions.create (3);
        m_lcssa_nodes.create (3);
    }



     
     
  • 7.65, Аноним (65), 19:35, 26/03/2020 [^] [^^] [^^^] [ответить]  
  • –3 +/
    С если без его извратских и лагонутых С классов - это как раз нормально, даж... большой текст свёрнут, показать
     
     
  • 8.71, Ordu (ok), 21:03, 26/03/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Как я понимаю, C лучше тем, что он даёт больше контроля за происходящим Если ты... текст свёрнут, показать
     
     
  • 9.83, Аноним (83), 09:31, 30/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Неверно На С можно делать тоже самое 1в1 Зато у него строже синтакисис у тип... большой текст свёрнут, показать
     
  • 6.47, llolik (ok), 16:06, 26/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    https://gcc.gnu.org/wiki/cxx-conversion
    Тут всё написано.
     
  • 6.58, Аноним (59), 18:19, 26/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    КО: Склонируй исходники, да посмотри.
     
     
  • 7.78, microsoft (?), 16:13, 27/03/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Тоестб тменно часть что отвеечает за С компилятор написана на С++? Можно мне ссылку.
     
  • 2.25, Аноним84701 (ok), 13:02, 26/03/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > То есть для того, чтобы запустить некую программу, скомпилированную с помощью llvm,
    > мне надо на целевой хост поставить, мнэ, интерпретатор llvm, выполняющий "скомпилированный"
    > код.
    > Наверное в этом есть какой-то смысл, но я не понимаю.

    Смысл в простом детекторе всех тех, кто толком не разобрался, но имеет "ценнейшее мнение":
    > The LLVM Project is a collection of modular and reusable compiler and toolchain technologies. Despite its name, LLVM has little to do with traditional virtual machines. The name "LLVM" itself is not an acronym; it is the full name of the project.
    >  Code Generation and Optimization
    >              This stage translates an AST into low-level intermediate code
    >              (known as "LLVM IR") and ultimately to machine code.  This phase
    >              is responsible for optimizing the generated code and handling
    >              target-specific code generation.  The output of this stage is
    >             typically called a ".s" file or "assembly" file
    >

     
     
  • 3.27, konrad (??), 13:13, 26/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    плюсую))
     
  • 3.36, Аноним (4), 14:01, 26/03/2020 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Я умею читать и даже осмыслить прочитанное.

    Вопрос - накой прослойка? Конпелятор нужен для максимальной производительности. А если дополнительно вкрячивается интерпретация байт-кода в платформу, то это не конпелятор.

     
     
  • 4.41, Аноним84701 (ok), 14:28, 26/03/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Я умею читать и даже осмыслить прочитанное.

    Угу-угу. Цитата из man clang
    >This stage translates an AST into low-level intermediate code
    >(known as "LLVM IR") and ultimately to machine code.

    для кого была?

    > Вопрос - накой прослойка? Конпелятор нужен для максимальной производительности.

    Ответ: за надом в виде оптимизации. Потому что далеко не все можно оптимизировать на уровне AST (например: лучше подходит (разновидность) той же абстрактой интерпретации). А без "прослойки" -- придется копипастить-писать часть низкоуровневой платфоромнезависимой оптимизации для каждой целевой платформы  (краткая лекция введения в компиляторостроение  или хотя бы  https://en.wikipedia.org/wiki/LLVM#Intermediate_representation и https://en.wikipedia.org/wiki/Intermediate_representation находятся в шаговой доступности от анонима).

    >  А если дополнительно вкрячивается интерпретация байт-кода в платформу, то это не конпелятор.

    Ну если аноним так говорит, то наверное так оно и есть. Правда, пацаны из GCC об этом почему-то не слышали:
    https://gcc.gnu.org/onlinedocs/gccint/Tree-SSA.html#Tree-SSA
    >GCC uses three main intermediate languages to represent the program during compilation: GENERIC, GIMPLE and RTL. GENERIC is a language-independent representation generated by each front end. It is used to serve as an interface between the parser and optimizer. GENERIC is a common representation that is able to represent programs written in all the languages supported by GCC.
    >

     
  • 4.42, Аноним (42), 14:37, 26/03/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Явно нет. Хочешь сорву покровы и скажу что gcc, в принципе, так же нынче работает?
     
  • 4.54, Аноним (54), 17:38, 26/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Конпелятор от слова conpile?
     
  • 4.66, Аноним (66), 19:45, 26/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Вопрос - накой прослойка?

    Ответ - в другом ответе выше:
    https://www.opennet.dev/opennews/art.shtml?num=52611#63

     

  • 1.15, Аноним (15), 11:55, 26/03/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Компилятор должен быть один, куда все контрибутят для всех платформ.
    И это не сабж. Сабж очередной выкидышЪ яббловой проприетарности.
     
     
  • 2.30, Аноним (-), 13:23, 26/03/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Good-но сказал, плюсую. Ещё на ранних стадиях, разработчики LLVM сперва тупо копировали фрагменты исходных кодов GCC в свой проект, и только потом его переписывали.
     
     
  • 3.67, Аноним (67), 19:50, 26/03/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    разработчики 90% opensource проектов когда имея проприетарный аналог/конкурента сперва тупо копировали фрагменты исходных дизассемблированных кодов в свой проект, и только потом его переписывали. Ибо так не толко быстрей, а и почти ~100%-ая совместимость сохраняется.

    Так что фиктивный аргумент.

     
  • 2.38, kai3341 (ok), 14:08, 26/03/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >  Компилятор должен быть один, куда все контрибутят для всех платформ.

    LLVM как раз претендует на эту роль

     
     
  • 3.73, Аноним (73), 21:04, 26/03/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    претендует... но сделали, как обычно.
     

  • 1.29, Аноним (29), 13:22, 26/03/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –9 +/
    Сначала во фрибсд, далее - везде! Пора таки уже и линуксе начать выкидывать гцц на мороз!
     
     
  • 2.31, Аноним (-), 13:24, 26/03/2020 [^] [^^] [^^^] [ответить]  
  • +5 +/
    ни бзди!
     
  • 2.33, microsoft (?), 13:33, 26/03/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Тебя спросить забыли
     
  • 2.37, Аноним (59), 14:07, 26/03/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    - Где-где?
    - В ...
    - О, и я о том же.
     

  • 1.48, Ilya Indigo (ok), 16:11, 26/03/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > По умолчанию прекращён запуск отдельного процесса ("clang -cc1"),

    Объясните, пожалуйста, зачем и чем это будет лучше?

     
     
  • 2.56, Замбога Бородуля (?), 17:45, 26/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    По идее для ускорения процесса сборки
     
     
  • 3.72, Аноним (73), 21:03, 26/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    что, запуск процесса идёт полчаса, что ли?!
     
     
  • 4.74, Аноним (74), 22:11, 26/03/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    На винде - примерно столько и идет, даже в два раза больше.
     
     
  • 5.77, Аноним (-), 14:23, 27/03/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Пруфы будут, г-н эксперт, или как всегда?
     
     
  • 6.79, Замбога Бородуля (?), 19:32, 27/03/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Пруфы чего? Что если создавать процесс, то это займёт время t = N, а не создавать t = 0?
     

  • 1.84, yurikoles (ok), 19:17, 31/03/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    LLVM - это проект 21го века, начат учёными, написан на современном языке, был рано замечен Apple и получил огромные инвестиции как раз когда Столлман решил скатить хорошую лицензию в новую версию, которая добавила только лишние проблемы всему рынку. Кроме FSF и GNU никто почти и не перешёл на неё. Сейчас многие крупные игроки уже осознанно выбирают между двумя проектами. И это прекрасно! Конкуренция заставляет оба проекта развиваться. Но пока из преимуществ GCC осталось только то, что на него завязана вся инфраструктура FLOSS, только из-за этого он и держится на плаву. Но и это преимущество не вечно, OpenMandriva уже полностью перешла. В Debian постоянно растёт доля пакетов, успешно собираемых Clang/LLVM. А производительность уже давно сравнялась, есть некоторые флуктуации в разные стороны.
     

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



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

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