The OpenNET Project / Index page

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

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

16.04.2021 12:16

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

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

  • Реализована и включена по умолчанию поддержка предложенных в стандарте C++20 атрибутов "likely" и "unlikely", позволяющих информировать оптимизатор о вероятности срабатывания условной конструкции (например, "[[likely]] if (random > 0) {").
  • Добавлена поддержка процессоров AMD Zen 3 (-march=znver3), Intel Alder Lake (-march=alderlake) и Intel Sapphire Rapids (-march=sapphirerapids).
  • Добавлена поддержка флагов "-march=x86-64-v[234]" для выбора уровней архитектуры x86-64 (v2 - охватывает расширения SSE4.2, SSSE3, POPCNT и CMPXCHG16B; v3 - AVX2 и MOVBE; v4 - AVX-512).
  • Добавлена поддержка процессоров Arm Cortex-A78C (cortex-a78c), Arm Cortex-R82 (cortex-r82), Arm Neoverse V1 (neoverse-v1), Arm Neoverse N2 (neoverse-n2) и Fujitsu A64FX (a64fx). Например, для включения оптимизаций для CPU Neoverse-V1 можно указать "-mcpu=neoverse-v1".
  • Для архитектуры AArch64 добавлены новые флаги компилятора "-moutline-atomics" и "-mno-outline-atomics", предназначенные для включения и отключения вспомогательных функций с реализацией атомарных операций, таких как "__aarch64_cas8_relax". Подобные функции во время выполнения определяют наличие поддержки расширений LSE (Large System Extensions) и используют предоставляемые атомарные процессорные инструкции или откатываются на использование инструкций LL/SC (Load-link/store-conditional) для синхронизации.
  • Добавлена опция "-fbinutils-version" для выбора целевой версии набора binutils для обеспечения совместимости со старым поведением компоновщика и ассемблера.
  • Для исполняемых файлов ELF при указании флага "-gz" по умолчанию включено сжатие отладочной информации с использованием библиотеки zlib (gz=zlib). Для компоновки результирующих объектных файлов требуется lld или GNU binutils 2.26+. Для восстановления совместимости со старыми версиями binutils можно указать "-gz=zlib-gnu".
  • Указатель 'this' теперь обрабатывается с проверками nonnull и dereferenceable(N). Для удаления атрибута nonnull, при необходимости использования значений NULL, можно использовать опцию "-fdelete-null-pointer-checks".
  • На платформе Linux для архитектур AArch64 и PowerPC включён режим "-fasynchronous-unwind-tables" для генерации "раскрученных" (unwind) таблиц вызовов, как в GCC.
  • В "#pragma clang loop vectorize_width" добавлена возможность указания опций "fixed" (по умолчанию) и "scalable" для выбора метода векторизации. Режим "scalable", независимый от длины вектора, является экспериментальным и может использоваться на оборудовании с поддержкой масштабируемой векторизации.
  • Улучшена поддержка платформы Windows: Подготовлены официальные бинарные сборки для Windows на системах Arm64, включающие компилятор Clang, компоновщик LLD и runtime-библиотеки compiler-rt. При сборке для целевых платформ MinGW реализовано добавление суффикса .exe, даже при выполнении кросс-компиляции.
  • Расширены возможности, связанные с поддержкой OpenCL, OpenMP и CUDA. Добавлены опции "-cl-std=CL3.0" и "-cl-std=CL1.0" для выбора вариантов макросов для OpenCL 3.0 и OpenCL 1.0. Расширены средства диагностики.
  • Добавлена поддержка инструкций HRESET, UINTR и AVXVNNI, реализованных в некоторых процессорах на базе архитектуры x86.
  • На системах x86 включена поддержка опции "-mtune=<cpu>", активирующей выбранные микроархитектурные оптимизации, независимо от значения "-march=<cpu>".
  • В статическом анализаторе улучшена обработка некоторых POSIX-функций и значительно улучшено определение результата условных операций при наличии в сравнении нескольких символьных значений. Добавлены новые проверки: fuchia.HandleChecker (определяет дескрипторы в структурах), webkit.UncountedLambdaCapturesChecker webkit и alpha.webkit.UncountedLocalVarsChecker (учитывают особенности работы с указателями в коде движка WebKit).
  • В выражениях, используемых в контексте констант, разрешено использование встроенных функций __builtin_bitreverse*, __builtin_rotateleft*, __builtin_rotateright*, _mm_popcnt*, _bit_scan_forward, __bsfd, __bsfq, __bit_scan_reverse, __bsrd, __bsrq, __bswap, __bswapd, __bswap64, __bswapq, _castf*, __rol* и __ror*.
  • В утилиту clang-format добавлена опция BitFieldColonSpacing для выбора расстановки пробелов вокруг идентификаторов, столбцов и определений полей.
  • В кеширующем сервере clangd (Clang Server) на платформе Linux значительно сокращено потребление памяти при длительной работе (обеспечен периодический вызов malloc_trim для отдачи свободных страниц памяти операционной системе).



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

  • Прекращена поддержка написанного на языке Python сборочного инструментария llvm-build, вместо которого проект полностью перешёл на использование сборочной системы CMake.
  • В бэкенде для архитектуры AArch64 улучшена поддержка платформы Windows: обеспечена корректная генерация ассемблерного вывода для целевых систем Windows, оптимизирована генерация данных о "раскрутке" (unwind) вызовов (размер подобных данных сократился на 60%), добавлена возможность создания unwind-данных при помощи ассемблерных директив .seh_*.
  • В бэкенде для архитектуры PowerPC реализованы новые оптимизации циклов и inline-развёртывания, расширения поддержка процессоров Power10, добавлена поддержка инструкций MMA для манипуляций с матрицами, улучшена поддержка операционной системы AIX.
  • В бэкенде для архитектуры x86 добавлена поддержка процессоров AMD Zen 3, Intel Alder Lake и Intel Sapphire Rapids, а также процессорных инструкций HRESET, UINTR и AVXVNNI. Прекращена поддержка расширений MPX (Memory Protection Extensions) для проверки указателей на соблюдение границ областей памяти (указанная технология не получила распространения и уже удалена из GCC и clang). В ассемблер добавлена поддержка префиксов {disp32} и {disp8} и суффиксов .d32 и .d8 для управления размером смещения операндов и переходов. Добавлен новый атрибут "tune-cpu" для управления включением микроархитектурных оптимизаций.
  • В детектор проблем при работе с целыми числами (integer sanitizer, "-fsanitize=integer") добавлен новый режим "-fsanitize=unsigned-shift-base" для выявления переполнений беззнаковых целых чисел после битового сдвига влево.
  • В различных детекторах (asan, cfi, lsan, msan, tsan, ubsan sanitizer) добавлена поддержка Linux-дистрибутивов с стандартной библиотекой Musl.
  • Расширены возможности компоновщика LLD. Улучшена поддержка формата ELF, в том числе добавлены опции "--dependency-file", "--error-handling-script", "--lto-pseudo-probe-for-profiling", "--no-lto-whole-program-visibility". Улучшена поддержка MinGW. Для формата Mach-O (macOS) реализована поддержка архитектур arm64, arm и i386, оптимизаций на этапе связывания (LTO) и раскрутки стека при обработке исключений.
  • В Libc++ реализованы новые возможности стандарта C++20 и началась разработка возможностей спецификации C++2b. Добавлена поддержка сборки с отключением поддержки локализации ("-DLIBCXX_ENABLE_LOCALIZATION=OFF") и устройств для генерации псевдо-случайных чисел ("-DLIBCXX_ENABLE_RANDOM_DEVICE=OFF").


  1. Главная ссылка к новости (https://lists.llvm.org/piperma...)
  2. OpenNews: Проект LLVM представил HPVM 1.0, компилятор для CPU, GPU, FPGA и ускорителей
  3. OpenNews: Релиз набора компиляторов LLVM 11.0
  4. OpenNews: В OpenBSD-current импортирован LLVM 10
  5. OpenNews: Разработчики LLVM обсуждают прекращение использования слова "master"
  6. OpenNews: Разработчики из Google предложили разработать свою libc для LLVM
Лицензия: CC-BY
Тип: Программы
Короткая ссылка: https://opennet.ru/54977-llvm
Ключевые слова: llvm, clang
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (61) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 12:40, 16/04/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Атрибут optimize ещё не прикрутили?
     
     
  • 2.5, Аноним (5), 12:49, 16/04/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Да вроде давно
     
     
  • 3.58, Аноним (58), 16:22, 17/04/2021 [^] [^^] [^^^] [ответить]  
  • +/
    В упор не наблюдаю https://clang.llvm.org/docs/AttributeReference.html Где?
     

  • 1.2, Аноним (2), 12:46, 16/04/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    А что там нынче с поддержкой плюсовых модулей?
     
     
  • 2.21, Аноним (21), 14:05, 16/04/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Ещё с 9 есть. Только в CMake их поддержки не завезли, придётся самому валандаться с аттрибутами коммандной строки. А мы ведь системы сборки для того и используем, чтобы с ними за нас валандалась система сборки. Поэтому, пока в системы сборок поддержку модулей не завезут, прок от использования модулей будет отрицательным.
     
     
  • 3.28, Аноним (28), 15:18, 16/04/2021 [^] [^^] [^^^] [ответить]  
  • +/
    В build2 (https://build2.org/) давно завезли (не путать с бустовым b2).
     
     
  • 4.54, Аноним (-), 10:44, 17/04/2021 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Это что-то совсем уж маздайное, начиная с способов даунлоада и "секурити" в виде SHA256 (Подписи GPG?! Не, не слышали!) и поддерживает аж полторы конфигурации. Из которых примерно 3/4 - маздайка. Которая мне например как таргет не интересна вообще. Так что убийцы cmake из этой штуки явно не вырисовывается. Маздайный апстрим == trouble on the way.
     
     
  • 5.68, Аноним (68), 23:29, 17/04/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Разработчики пользуются то ли маком, то ли линуксом (возможно, и тем и другим). Бинарные пакеты build2 есть под большинство дистрибутивов Linux - Ubuntu/Debian, Fedora, RedHat/CentOS, вроде есть под Arch и Gentoo (под винду и мак, кстати, вроде нет). Правда, все они неофициальные, потому что официальный способ - собирать из исходников, но бинарные пакеты стабильно поддерживаются и ссылки есть на официальном сайте. Build2 поддерживает сборку приложений под Linux, Win, Mac, FreeBSD, причем даже в своем CI.

    Ты, похоже, про какой-то не тот build2 пишешь.

     
  • 4.69, Аноним (69), 02:40, 18/04/2021 [^] [^^] [^^^] [ответить]  
  • +/
    build2 для программ без сторонних библиотек (хеллоу ворлдов), потому как все сторонние библиотеки ориентированы на CMake
     
  • 2.70, Аноним (69), 02:44, 18/04/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > А что там нынче с поддержкой плюсовых модулей?

    Плохо, пока нет ни одного компилятора, который их поддерживает в полной мере.

    https://en.cppreference.com/w/cpp/compiler_support/20

     

  • 1.3, Аноним (3), 12:48, 16/04/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    > На системах x86 включена поддержка опции "-mtune=<cpu>"

    Дааа..... Когда же они тогда весь GCC перепишут?!

     
  • 1.7, menangen (?), 12:55, 16/04/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Что там с модулями? Как их заставить работать с Xcode?
     
     
  • 2.22, Аноним (21), 14:05, 16/04/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Никак.
     
     
  • 3.52, Аноним (52), 04:42, 17/04/2021 [^] [^^] [^^^] [ответить]  
  • +/
    А жаль.
     

  • 1.10, Анонас (?), 13:00, 16/04/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +18 +/
    > Реализована и включена по умолчанию поддержка предложенных в стандарте C++20 атрибутов "likely" и "unlikely", позволяющих информировать оптимизатор о вероятности срабатывания условной конструкции

    А "highly likely" почему не добавили?

     
     
  • 2.12, anonymous (??), 13:15, 16/04/2021 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Ты хочешь сказать, что русские хакеры могут вмешаться в исход условного оператора if???
     
     
  • 3.30, ng (?), 15:21, 16/04/2021 [^] [^^] [^^^] [ответить]  
  • +4 +/
    С точки зрения ламера есть несколько вариантов (в нотации ASM х86):
    - поменять условный переход на безусловный по тому же адресу: JZ => JMP;
    - поменять логику перехода сохранив адрес перехода: JZ => JNZ;
    - исключить проверку и переход вообще: J(x) => NOP;
    - наверняка, существуют и другие способы "вмешательства в исход условного оператора", известные хакерам безотносительно их национальной принадлежности.

    imho

     
     
  • 4.38, Rndanon (?), 16:50, 16/04/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Лови русского(советского?) хакера!
     
  • 2.15, Аноним (15), 13:34, 16/04/2021 [^] [^^] [^^^] [ответить]  
  • +/
    С гцц оно существует с какого года? С 2000?
     
     
  • 3.18, жопка3 (?), 13:43, 16/04/2021 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Вы путаете аттрибуты стандарта C++ и аттрибуты поддерживаемые компилятором.
     
     
  • 4.24, Аноним (3), 14:20, 16/04/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А есть разница на результирующий код? Или ты из секты синтаксической соли?
     
     
  • 5.26, Аноним (26), 14:47, 16/04/2021 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Ну с сишного register есть, причём ради интереса замерял простенький цикл со счётчиком и ускорение было в 10000 раз. По факту приложение в итоге начало отрабатывать в 1000 раз быстрее. А видишь из плюсов выкинули.
     
     
  • 6.29, Аноним (28), 15:20, 16/04/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ой, всё...
     
     
  • 7.32, Аноним (26), 15:42, 16/04/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Ой, всё...

    Хорошая новость: пго этот цикл тоже соптимизировал, даже ещё лучше. Плохая: без пго единственная надежда на такие подсказки от кодера.

     
     
  • 8.57, Аноним (-), 10:59, 17/04/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Что вы там вообще делали Простой цикл со счетчиком gcc например обычно випилыва... текст свёрнут, показать
     
     
  • 9.65, Аноним (26), 19:28, 17/04/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Цикл не был пустым естественно, он был динамическим и зависел от внешних данных ... текст свёрнут, показать
     
  • 6.55, Аноним (-), 10:49, 17/04/2021 [^] [^^] [^^^] [ответить]  
  • +/
    По состоянию на *сейчас* register как правило не дает совсем никакого эффекта. Компилер и так допрет загнать "горячие" вещи в регистры, покуда их хватает. Собственно поэтому его и убрали...

    Ну или давайте конкретный пример
    - Конфигурации. Компилер, ось, проц, опции.
    - Кода где от register есть какой-то толк. Я проверю.

    Интерес потому что я пробовал так и сяк и вообще разницу в кодогенерации (как минимум на ARM) так сразу получить не смог.

     
     
  • 7.64, Аноним (26), 19:26, 17/04/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Это был gcc7 linux amd64 проц какой-то тех лет от интела, O2 и native. Разница в кодогенерации была, и была разница в производительности. Кода у меня нет, там было что-то банальное типа for(int i;i<100500;++i) компилятор не стал это оптимизировать и счётчик в регистры не назначался.
     

  • 1.16, Аноним (16), 13:36, 16/04/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    С++20 все еще не полностью поддерживается
     
     
  • 2.19, Аноним (19), 13:48, 16/04/2021 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Да и ладно. А что там gcc выступал? Вот на сабжа и заменим.
     
     
  • 3.31, Аноним (31), 15:31, 16/04/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Сабж не выступал против Столмана потому, что он и так под пятой у проприерастов, а не под руководством FSF.
     
  • 3.42, макпыф (ok), 18:05, 16/04/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    gcc не выступал и не может так его пилит проект GNU которым столман управляет.
    а вот llvm выступить может.
     
     
  • 4.47, Аноним (-), 19:18, 16/04/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Нет. GCC не выступил потому, что они преданные соратники Столлмана.
     
     
  • 5.48, Аноним (-), 19:24, 16/04/2021 [^] [^^] [^^^] [ответить]  
  • –8 +/
    > Нет. GCC не выступил потому, что они преданные соратники Столлмана.

    Кем именно преданные? Столлманом?


     
  • 4.51, макпыф (ok), 22:10, 16/04/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > gcc не выступал и не может так его пилит проект GNU которым
    > столман управляет.
    > а вот llvm выступить может.

    если кто то сомневаеться: https://ru.wikipedia.org/wiki/GNU_Compiler_Collection
    > Разработчик Проект GNU

    а лидер проекта gnu - столман
    поэтому столман не может выступить сам против себя (раздвоения личности у него вроде нету)

     
     
  • 5.59, Аноним (58), 16:24, 17/04/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Ты GNU c FSF не попутал?
     
     
  • 6.60, макпыф (ok), 16:26, 17/04/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > Ты GNU c FSF не попутал?

    нет.
    fsf тут причем? да, сора из за него, но проектом GNU тоже руководит столман

     
  • 2.62, acroobat (ok), 17:22, 17/04/2021 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > С++20 все еще не полностью поддерживается

    C++ is dead

     

  • 1.25, Аноним (25), 14:41, 16/04/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    AVX512 то еще говно по слвоам Линуса. AVX2 уже давно есть. -march=native решает трудности выбора нужных инструкций. Но можно выключить ненужное, для чего и есть уровни 3 и 2.
     
     
  • 2.61, Аноним (58), 16:28, 17/04/2021 [^] [^^] [^^^] [ответить]  
  • +/
    На локалхосте у себя под одеялом собирать не вопрос конечно. Но распространять такие бинари бессмысленно.
     

  • 1.27, YetAnotherOnanym (ok), 15:16, 16/04/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    > "likely" и "unlikely"

    Надо ещё  "highly likely" и "highly unlikely", а лучше - всю шкалу от "nearly impossible" до "almost certain".

     
     
  • 2.40, Какаянахренразница (ok), 17:19, 16/04/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    От "да ни в жисть" до "мамой клянусь".
     
     
  • 3.56, Аноним (-), 10:52, 17/04/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну это вам язык РАПИРА надо. Еще можно б#% буду! добавить. Хотя в принципе одно время такой синтаксис катитл и в MSовском сишном компилере, загуглить про "какой-то козел стал гoвнистость". Но это нестандарт, другие компилеры не жрут.
     

  • 1.33, acroobat (ok), 16:00, 16/04/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Есть поддержка D?
     
     
  • 2.34, Аноним (31), 16:04, 16/04/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    D там отдельно, LDC называется.
     
     
  • 3.36, acroobat (ok), 16:15, 16/04/2021 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Тогда нужно
     

  • 1.35, adolfus (ok), 16:05, 16/04/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    likely, unlikely ...
    Глупости все это -- управление предвыборкой. Не все платформы умеют это делать. ia32 и amd64 в подявляющем большинстве случаев не могут эти хинты эффективно обработать.
    Самый действенный метод повысить призводительность вычислений -- писать всю математику на фортране или прямо на ассемблере платформы.
     
     
  • 2.37, Твой батя (?), 16:45, 16/04/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А если это не математика, а какой-нибудь обработчик событий в GUI? Тоже на фортране или ассемблере писать?
     
     
  • 3.44, Аноним (3), 18:10, 16/04/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > обработчик событий в GUI

    Вот уж кому не впёрлись все эти лайки.

     
  • 2.41, Аноним (41), 18:00, 16/04/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Причём тут, блин, математика?

    Вот есть у меня код разбора протокола http. Если первый символ G, то очень даже likely, что второй E, а третий T.

     
     
  • 3.45, Аноним (3), 18:12, 16/04/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    И причём тут лайки, если ты уже сам составил дерево разбора так, как надо?!
     
     
  • 4.63, Tim (??), 19:01, 17/04/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    В условии if-else две ветки выполнения. Для компилятора они равновероятны.
    Если не повезёт, в коротком цикле окажется сброс конвейера.

    На пример с GET, возможен сброс после каждого символа.

     
     
  • 5.66, Аноним (3), 20:00, 17/04/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Тебе не повезло с процом, если он у тебя конвейер сбрасывает. Процы уже давно спекулятивно исполняют обе ветки после ветвления, отбрасывая потом ненужную уже фоном. Это появилось вскоре, как сделали переименовку регистров.
     
     
  • 6.71, Tim (??), 07:47, 18/04/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Такой ерундой страдал 4-ый пень, и грелся аж песец.
    Новые процы спекулятивно выполняют только одну ветку.
    Или ведут статистику переходов, ака динамическое предсказание, или эвристика... типа к младшим адресам значит цикл, к старшим значит переход маловероятен.
    В общем пользуй PGO либо ставь атрибуты.
     
  • 2.43, Чтото странное ты пишешь (?), 18:06, 16/04/2021 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Не умеют и не умеют, в чём проблема-то?
     
  • 2.72, Алкоголик Анон (?), 18:02, 18/04/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > likely, unlikely ...
    > Глупости все это -- управление предвыборкой. Не все платформы умеют это делать.
    > ia32 и amd64 в подявляющем большинстве случаев не могут эти хинты
    > эффективно обработать.
    > Самый действенный метод повысить призводительность вычислений -- писать всю математику
    > на фортране или прямо на ассемблере платформы.

    При чём тут предвыборка вообще?

    Например в каком-то маловероятном случае может требоваться крупный массив.

    // ...
    if(content_coded) [[unlikely]] {
       int buffer[16*1024*1024];
       /* decode content */
    }
    return content[0];
    // :-)

    Ну вот. Без unlikely оптимизирующий компилятор может резервировать память под buffer каждый раз при вызове функции (ещё до проверки чего-либо). Также может влиять на inlining...

     

  • 1.46, Иван (??), 18:18, 16/04/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    > На платформе Linux для архитектур AArch64 и PowerPC включён режим
    > "-fasynchronous-unwind-tables" для генерации "раскрученных"
    > (unwind) таблиц вызовов, как в GCC.

    Поправьте пожалуйста перевод.

    "unwind tables" это таблицы для раскрутки стека, а не "раскрученные" таблицы. Асинхронные таблицы раскрутки стека позволяют раскручивать стек в любой точке (на любой инструкции), а не только в точках вызова функций.

     
  • 1.49, Аноним (-), 19:39, 16/04/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >Релиз набора компиляторов LLVM 12.0

    Он даже название GCC копируют. Типа: "набора компиляторов".

     
  • 1.53, Аноним (53), 09:52, 17/04/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > поддержкой OpenCL, OpenMP и CUDA. Добавлены опции "-cl-std=CL3.0" и "-cl-std=CL1.0"

    OpenCL у писателей дров к видяхам на самом последнем месте: https://mesamatrix.net

    Хотя бы для видях AMD сделали полную поддержку "-cl-std=CL1.2"

     
     
  • 2.67, Аноним (26), 20:45, 17/04/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Это такой намёк "берите nvidia и блоб", сама nvidia использует наработки llvm в той же cuda.
     

  • 1.73, iZEN (ok), 18:43, 20/04/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    На FreeBSD сейчас обязательно присутствует ТРИ версии LLVM: системный, LLVM 10.0 для mesa-dri, LLVM 11.0 для Firefox и Thunderbird. И ещё LLVM 9.0 и GCC 10 для сборки чего-то там используется, но это не считается - их можно удалить по окончании сборки.

    Вот такой вот "зоопарк" версий, как у MS .Net в своё время.

     

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



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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