The OpenNET Project / Index page

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

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

05.10.2021 12:00

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

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

  • Реализована поддержка гарантированных хвостовых вызовов (вызов подпрограммы в самом конце функции, образующий хвостовую рекурсию в случае, если подпрограмма вызывается саму себя). Поддержка гарантированных хвостовых вызовов обеспечена при помощи атрибута "[[clang::musttail]]" в C++ и "__attribute__((musttail))" в C, применяемых в выражении "return". Возможность позволяет реализовать оптимизации через развёртывание кода в плоскую итерацию для экономии расходования стека.
  • В декларациях "using" и расширениях clang реализована поддержка определения атрибутов в стиле C++11, используя формат "[[]]".
  • Добавлен флаг "-Wreserved-identifier" для вывода предупреждения при указании в пользовательском коде зарезервированных идентификаторов.
  • Добавлены флаги "-Wunused-but-set-parameter" и "-Wunused-but-set-variable" для вывода предупреждения, если параметр или переменная выставлены, но не используются.
  • Добавлен флаг "-Wnull-pointer-subtraction" для вывода предупреждения, если в код может привести к неопределённому поведению из-за использования нулевого указателя в операциях вычитания.
  • Добавлен флаг "-fstack-usage" для генерации для каждого файла с кодом дополнительного файла ".su", содержащего сведения о размере кадров стека для каждой функции, определённой в обрабатываемом файле.
  • В статическом анализаторе добавлен новый тип вывода - "sarif-html", приводящий к формированию отчётов одновременно в форматах HTML и Sarif. Добавлена новая проверка allocClassWithName. При указании опции "-analyzer-display-progress" обеспечен вывод времени анализа каждой функции. Почти доведён до готовности анализатор умных указателей (alpha.cplusplus.SmartPtr).
  • Расширены возможности, связанные с поддержкой OpenCL. Добавлена поддержка новых расширений cl_khr_integer_dot_product, cl_khr_extended_bit_ops, __cl_clang_bitfields и __cl_clang_non_portable_kernel_param_types. Продолжена реализация спецификации OpenCL 3.0. Для Си по умолчанию задействована спецификация OpenCL 1.2, если явно не выбрана другая версия. Для C++ добавлена поддержка файлов с расширением ".clcpp".
  • Реализована поддержка директив трансформации циклов ("#pragma omp unrol" и "#pragma omp tile"), определённых в спецификации OpenMP 5.1.
  • В утилиту clang-format добавлены опции: SpacesInLineCommentPrefix для определения числа пробелов перед комментариями, IndentAccessModifiers, LambdaBodyIndentation и PPIndentWidthдля управления выравниванием записей, лямбда-выражений и директив препроцессора. Расширены возможности сортировки перечисления заголовочных файлов (SortIncludes). Добавлена поддержка форматирования файлов JSON.
  • В linter clang-tidy добавлена большая порция новых проверок.

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

  • Добавлена опция "-ehcontguard" для использования технологии CET (Windows Control-flow Enforcement Technology) для защиты на этапе обработки исключений от выполнения эксплоитов, построенных с использованием приёмов возвратно-ориентированного программирования (ROP, Return-Oriented Programming).
  • Проект debuginfo-test переименован в cross-project-tests и рассчитан на тестирование компонентов из различных проектов, не ограничиваясь отладочной информацией.
  • В сборочной системе обеспечена поддержка сборки нескольких дистрибутивов, например, один с утилитами, а второй с библиотеками для разработчиков.
  • В бэкенде для архитектуры AArch64 в ассемблере реализована поддержка расширений Armv9-A RME (Realm Management Extension) и SME (Scalable Matrix Extension).
  • В бэкенд для архитектуры Hexagon добавлена поддержка ISA V68/HVX.
  • В бэкенде для архитектуры x86 улучшена поддержка процессоров AMD Zen 3.
  • В бэкенд AMDGPU добавлена поддержка APU GFX1013 RDNA2.
  • В Libc++ продолжена реализация новых возможностей стандартов C++20 и C++2b, в том числе завершена реализация библиотеки "concepts". Для платформы Windows на базе MinGW добавлена поддержка std::filesystem. Разделены заголовочные файлы <algorithm>, <iterator> и <utility>. Добавлена сборочная опция LIBCXX_ENABLE_INCOMPLETE_FEATURES для отключения заголовочных файлов с не полностью реализованной функциональностью.
  • Расширены возможности компоновщика LLD, в котором реализована поддержка Big-endian процессоров Aarch64, а бэкенд Mach-O доведён до состояния, позволяющего компоновать обычные программы. Включены улучшения, необходимые для компоновки Glibc с использованием LLD.
  • В утилиту llvm-mca (Machine Code Analyzer) добавлена поддержка процессоров, выполняющих инструкции по порядку (in-order superscalar pipeline), таких как ARM Cortex-A55.
  • В отладчике LLDB для платформы AArch64 реализована полная поддержка аутентификации указателей (Pointer Authentication), механизма MTE (MemTag, Memory Tagging Extension) и регистров SVE. Добавлены команды, позволяющие привязать теги к каждой операции выделения памяти и организовать при доступе к памяти проверку указателя, который должен быть связан с корректным тегом.
  • В состав формируемых проектом бинарных сборок добавлены отладчик LLDB и фронтэнд для языка Fortran - Flang.


  1. Главная ссылка к новости (https://lists.llvm.org/piperma...)
  2. OpenNews: Релиз набора компиляторов LLVM 12.0
  3. OpenNews: Проект LLVM представил HPVM 1.0, компилятор для CPU, GPU, FPGA и ускорителей
  4. OpenNews: Релиз набора компиляторов LLVM 11.0
  5. OpenNews: Разработчики LLVM обсуждают прекращение использования слова "master"
  6. OpenNews: Разработчики из Google предложили разработать свою libc для LLVM
Лицензия: CC-BY
Тип: Программы
Короткая ссылка: https://opennet.ru/55898-llvm
Ключевые слова: llvm, clang
Поддержать дальнейшую публикацию новостей на OpenNET.


Обсуждение (94) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 12:04, 05/10/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Супер! Молодцы!
     
     
  • 2.2, Аноним (1), 12:05, 05/10/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Ждем во фряшечке. Вот и свежий зен подвезли.
     
     
  • 3.10, Аноним (1), 12:59, 05/10/2021 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Проверил. В портах уже добавили.
     
     
  • 4.20, анонн (ok), 14:24, 05/10/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Проверил. В портах уже добавили.

    Нет. В портах - все еще RC4.


     
     
  • 5.32, Аноним (1), 17:00, 05/10/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Точно. Со слепу просмотрел. Спасибо!
     
  • 5.91, Аноним (1), 01:49, 08/10/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Теперича таки в портах.
     
  • 4.38, Ivan_83 (ok), 18:04, 05/10/2021 [^] [^^] [^^^] [ответить]  
  • +/
    В портах само по себе не сильно интересно, интереснее когда затащат в базу и когда для месы начнут юзать.
     
     
  • 5.39, Аноним (1), 18:13, 05/10/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Согласен. Но с чего-то надо начинать...
     

  • 1.3, Аноним (3), 12:07, 05/10/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    судя по номеру таки production ready
     
  • 1.4, Аноним (4), 12:08, 05/10/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Почему он так долго компи лируется начиная с 12? Судя по логу ощущение что он зависает часов на 20, но это не так и нужно ждать.
     
     
  • 2.5, QwertyReg (ok), 12:11, 05/10/2021 [^] [^^] [^^^] [ответить]  
  • –11 +/
    Или надо просто выкинуть свой Pentium 4 и компилировать на современном железе.
     
     
  • 3.6, Аноним (4), 12:13, 05/10/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > Или надо просто выкинуть свой Pentium 4 и компилировать на современном железе.

    11 то нормально компилируется

     
     
  • 4.7, Аноним (4), 12:16, 05/10/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Я посмотрел, 16 часов против 50 минут.
     
     
  • 5.8, Аноним (8), 12:37, 05/10/2021 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Пора переписывать на Rust.
     
     
  • 6.11, Аноним (1), 13:00, 05/10/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Это ты со сборками линуксов перепктал. В бсдях все православно. Патриархально. Профессура шалить не дает.
     
     
  • 7.14, Аноним (8), 13:16, 05/10/2021 [^] [^^] [^^^] [ответить]  
  • +/
    И что, в БЗДях ещё не вкатили Rust?
     
     
  • 8.15, Аноним (1), 13:27, 05/10/2021 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Как в линуксе Неее ... текст свёрнут, показать
     
  • 8.80, malloc (?), 09:39, 06/10/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Они там неосиляторы Все как один - профессора ... текст свёрнут, показать
     
  • 6.93, burjui (ok), 06:02, 08/10/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Чтобы компилилось так же или ещё дольше.
     
  • 5.22, еуые (?), 14:34, 05/10/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Это явно баг, но если вы об этом не сообщие в их багзилу https://llvm.org/docs/HowToSubmitABug.html то никто об этом не узнает и не исправит.
     
  • 5.23, Попандопала (?), 14:48, 05/10/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Тут советовали включать USE="pgo" вдруг поможет. Сейчас синкну и посмотрю. Ешё ccache есть,но я его не осилил.(
     
     
  • 6.24, Попандопала (?), 15:05, 05/10/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    2021-08-24T10:07:01 >>> sys-devel/llvm: 4 hours, 31 minutes, 59 seconds
     
     
  • 7.25, Попандопала (?), 15:13, 05/10/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    2021-08-24T10:07:01 >>> sys-devel/llvm-12.0.1: 4 hours, 31 minutes, 59 seconds
    Не тот.(
     
     
  • 8.45, Попандопала (?), 19:33, 05/10/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    2021-08-24T10 07 01 sys-devel llvm-12 0 1 4 hours, 31 minutes, 59 seconds 2... текст свёрнут, показать
     
     
  • 9.48, Аноним (4), 21:37, 05/10/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Так llvm у меня полчаса компилируется А вот шланг 8230 ... текст свёрнут, показать
     
     
  • 10.77, Попандопала (?), 09:23, 06/10/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    2021-07-10T21 20 55 sys-devel clang-12 0 1 1 hour, 11 minutes, 32 seconds 2... текст свёрнут, показать
     
  • 6.43, n00by (ok), 19:24, 05/10/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Profile-guided optimization (PGO) https://ru.wikipedia.org/wiki/Profile-guided_optimization
    наоборот увеличивает время компиляции (поскольку делает это дважды). И для sys-devel/llvm такой USE не вижу. Есть для sys-devel/gcc.

    А с ccache какие сложности?

    Добавляется в /etc/portage/make.conf

    FEATURES="${FEATURES} ccache"
    CCACHE_DIR="/var/tmp/ccache"
    KBUILD_BUILD_TIMESTAMP='00:00:00'

    и вроде всё. Последняя строка не обязательна - она позволяет использовать ccache для сборки ядра.
    Ну и ccache сконфигурировать для /var/tmp/ccache (или где будет кеш).

     
     
  • 7.46, Попандопала (?), 19:35, 05/10/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Для ГСС этот флаг им же и собирается. ЛЛВМ не все может собрать.
     
     
  • 8.74, n00by (ok), 08:08, 06/10/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Имею ввиду, что в ebuild для llvm USE-флаг pdo отсуствует То есть он ничего не ... текст свёрнут, показать
     
     
  • 9.78, Попандопала (?), 09:28, 06/10/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Как я понимаю этот флаг создает некий профиль и потом компилит изменения при сле... текст свёрнут, показать
     
     
  • 10.83, n00by (ok), 14:08, 06/10/2021 [^] [^^] [^^^] [ответить]  
  • +/
    А, теперь понял, что имелось ввиду Да, Вы правы Если GCC собрать с PGO, он буд... текст свёрнут, показать
     
  • 5.40, Ordu (ok), 18:27, 05/10/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Я бы предположил, что у тебя оперативка кончилась, и процесс сборки начал свопиться. Хотя, конечно, это гадание на кофейной гуще.
     
     
  • 6.56, Аноним (4), 23:01, 05/10/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Вполне возможно, но нет никакой дисковой активности и висит 1 процесс по 10+ часов -- вывод никак не меняется. Попробовал уполовинить число потоков, стало ощутимо дольше.
     
     
  • 7.64, Ordu (ok), 00:25, 06/10/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Вон у меня сейчас как раз, по счастливому совпадению , собирается llvm-13 Вот ... большой текст свёрнут, показать
     
     
  • 8.68, Аноним (4), 00:42, 06/10/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Со сборкой llvm у меня проблем нет, сопоставимо с gcc по веремени У меня пробле... текст свёрнут, показать
     
     
  • 9.69, Аноним (4), 00:43, 06/10/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Хотя не, gcc 15 минут и llvm 60 минут, в 4 раза медленнее выходит ... текст свёрнут, показать
     
     
  • 10.70, Аноним (4), 00:44, 06/10/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    От 40 до 60 ... текст свёрнут, показать
     
  • 9.71, Ordu (ok), 01:21, 06/10/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Ну я могу лишь посочувствовать ... текст свёрнут, показать
     
  • 8.72, n00by (ok), 07:27, 06/10/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Можно посмотреть qlop llvm это из app-portage portage-utils... текст свёрнут, показать
     
     
  • 9.79, Попандопала (?), 09:30, 06/10/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    qlop -vHt rust Так с версией покажет ... текст свёрнут, показать
     
  • 9.90, Ordu (ok), 01:11, 08/10/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Забавно Не знал про такое Два с половиной часа для всех с 9 по 13 версию, отде... текст свёрнут, показать
     
  • 3.18, Аноним (18), 14:09, 05/10/2021 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Нужно закрыть хлебало, прежде чем указывать людям, что им выкинуть, а что нет. Как оплатишь разработку и производство процессора под их нужды и подаришь им его бесплатно - так сразу и выкинут.
     
     
  • 4.21, QwertyReg (ok), 14:28, 05/10/2021 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Это СПО - делаешь сам, на чистом энтузиазме. Какие деньги?
     
  • 3.27, Аноним (27), 15:44, 05/10/2021 [^] [^^] [^^^] [ответить]  
  • +/
    В ссылку тебя надо с такими комментариями.
     
  • 2.9, Аноним (9), 12:59, 05/10/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Вспоминаю как на своей макоси собирал 11 версию (в Homebrew тогда бинарник ещё не завезли). Эта вещь пять часов компилировалась и из-за этого чуть не опоздал на работу.
     
     
  • 3.12, Аноним (1), 13:02, 05/10/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ты так говоришь, как буд-то в длительном конпелянии что-то плозое. Ты можешь откинуться на спинку стула и медитировать, глядя на пробегающие по экрану символы. Представлять, как буд-то и земля и небо все состоит из них.
     
  • 2.16, BorichL (ok), 13:44, 05/10/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А он под все доступные архитектуры собирается или только под нужные?
     
     
  • 3.30, pavlinux (ok), 16:34, 05/10/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > ... или только под нужные?

    PDP-11 не поддерживает :(((

     
     
  • 4.34, Аноним (34), 17:09, 05/10/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Ну это-то явное дно. Как можно без PDP-11?
     
     
  • 5.36, pavlinux (ok), 17:19, 05/10/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >  Как можно без PDP-11?

    Плохо  без них, сильные программисты больше не нужны.


     

  • 1.13, Аноним (13), 13:03, 05/10/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –7 +/
    Есть такая проблема подтверждаю , но приходится выбирать "собирается дольше , но после ui летает" или "собирается по олд стандартной модели быстро собирается , но позже собранная библиотека хуже и тормознее работает" , но есть идея пере собрать сами компиляторы C++20 с помощью C++2a или C++2b и вернуть в олд стандарт по причине сборки в общем никто не говорил что будет легко , а как известно в россии то уж тем более это не работает тут все хотят только деньги получать при том сразу и не работать т.е не заниматься пере сборкой пере меинфреимом
     
  • 1.19, zram (?), 14:19, 05/10/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Ебилды уже есть. Идёт собирать...
     
  • 1.26, Аноним (27), 15:42, 05/10/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Отлично проделанная работа. Долгих лет проекту.
     
  • 1.29, pavlinux (ok), 16:11, 05/10/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > __attribute__((musttail)) ...

    Вот сейчас хорошо было

     
     
  • 2.31, Урри (ok), 16:53, 05/10/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    gcc это (tail-call optimization) вроде как уже 20 лет умеет, без всяких там __attribute__.

    Вот сейчас проверил, 4.1.2 точно оптимизирует. А версии ниже у меня под руками нет.

     
     
  • 3.35, pavlinux (ok), 17:16, 05/10/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > gcc это (tail-call optimization) вроде как уже 20 лет умеет

    Так новость вроде про LLVM

     
     
  • 4.37, Урри (ok), 17:32, 05/10/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну да - про ллвм, который научился с костылями делать то, что можно было научиться делать давным-давно и без костылей.
     
     
  • 5.42, Ordu (ok), 18:36, 05/10/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Знаток в треде?

    llvm выполнял tail-call оптимизации столько, сколько я с ним имел дело. Но, tail-call оптимизация -- это то, что компилятор может делать, может не делать. Как минимум, на его решение оптимизировать или нет влияет заказанный уровень оптимизации. Возможно влияет что-то ещё, тут я не скажу.

    Атрибут musttail, что в gcc, что в llvm, делает tail-call оптимизацию обязательной. На любом уровне оптимизаций, даже на -O0. Предположу, что этот атрибут нужен для тех случаев, когда код, написанный в функциональном стиле, рекурсией обрабатывает огромные массивы, и из-за этого в debug-сборках переполняет все разумные размеры стека.

     
     
  • 6.50, Урри (ok), 21:57, 05/10/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Атрибут musttail, что в gcc, что в llvm, делает tail-call оптимизацию обязательной.

    int recursion(int x, int n)
    {
        if (n == 0)
            return x;

        int r = x * recursion(x-2, n-1);
        int q = n + recursion(x+2, n-1);

        return q * r;
    }

    Оптимизируй "обязательно".

     
     
  • 7.52, Ordu (ok), 22:28, 05/10/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Ты ворвался в тред с обвинениями llvm в том, что он такую полезную фичу запилил только сейчас. Но теперь, ты доказываешь, что фича бесполезная. Либо фича полезная, и тогда ты сейчас несёшь бред. Либо фича бесполезная, и тогда ты бред нёс раньше.
     
     
  • 8.59, Урри (ok), 23:35, 05/10/2021 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Нет Я угораю со знатоков, которые радуются, что шланг научился из любой рекурси... текст свёрнут, показать
     
     
  • 9.65, Ordu (ok), 00:27, 06/10/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Сам придумал, приписал другим, сам порадовался находке Зачем парился писать об ... текст свёрнут, показать
     
  • 7.54, Аноним (-), 22:41, 05/10/2021 [^] [^^] [^^^] [ответить]  
  • +/
    >> tail-call оптимизацию обязательной.
    >     int r = x * recursion(x-2, n-1);
    >     int q = n + recursion(x+2, n-1);
    >     return q * r;
    > Оптимизируй "обязательно".

    /0

     
     
  • 8.57, Урри (ok), 23:13, 05/10/2021 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Нэт Оно работает и не 0 - проверить минута времени ... текст свёрнут, показать
     
     
  • 9.81, Аноним (-), 13:01, 06/10/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Прочитать, что такое tail-call и перестать пороть чушь - тоже минута времени ... текст свёрнут, показать
     
     
  • 10.84, Урри (ok), 18:05, 06/10/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Еще один аноним прибежал преобразовывать функцию в обязательную хвостовую рекурс... текст свёрнут, показать
     
     
  • 11.85, Аноним (-), 20:37, 06/10/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Расскажи, в каких именно буковках ты сумел углядеть преобразовывать фун... большой текст свёрнут, показать
     
  • 3.47, анонн (ok), 20:46, 05/10/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> _гарантированных_ хвостовых вызовов
    >> If a return statement is marked musttail, this indicates that the compiler must generate a tail call for the program to be correct, even when optimizations are disabled.
    > gcc это (tail-call optimization) вроде как уже 20 лет умеет, без всяких там __attribute__.

    Т.е. в лучши традициях опеннета, ты либо не читал новость дальше заголовка, либо не знаешь, чем отличается _возможная_ tail call оптимизация от _гарантированной_?

    > Вот сейчас проверил, 4.1.2 точно оптимизирует. А версии ниже у меня под руками нет.

    Ну-ну.
    https://www.mail-archive.com/gcc@gcc.gnu.org/msg95265.html
    > Fri, 23 Apr 2021 12:45:18 -0700
    > Would it be feasible to implement a "musttail" statement attribute in
    > GCC to get a guarantee that tail call optimization will be performed?
    > Such an attribute has just landed in the trunk of Clang
    > (https://reviews.llvm.org/D99517).
    >

     
     
  • 4.49, Урри (ok), 21:55, 05/10/2021 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > чем отличается _возможная_ tail call оптимизация от _гарантированной_?

    Оу, даже гарантированной? Ого, какие новые интересные глубины открывают анонимы опеннета.
    А не оптимизирует ли гарантированно уважаемый гуру вот такую простую рекурсию?

    int recursion(int x, int n)
    {
        if (n == 0)
        return x;

        int r = x * recursion(x-2, n-1);
        int q = n + recursion(x+2, n-1);

        return q * r;
    }

    А я пока схожу в магаз за попкорном.

    > Ну-ну.
    > https://www.mail-archive.com/gcc@gcc.gnu.org/msg95265.html

    Сам по ссылке ходил то, аноним? Или нагуглил первое, не глядя тыкнул и "смааатрите, какой я Тузик, ой, Герой!"

    Ссылка: https://blog.reverberate.org/2021/04/21/musttail-efficient-interpreters.html

    Большой разбор и в конце цитата:

    ---
    One of the biggest caveats with this approach is that these beautiful assembly sequences get catastrophically pessimized if any non tail calls are present. Any non tail call forces a stack frame to be created, and a lot of data spills to the stack.
    ---

    Специально для тебя, анонимчик, повторю: IF ANY NON TAIL CALLS ARE PRESENT.

    --------------------------
    Все, вымерли программисты. Элементарнейшее понятие, - рекурсия, - им уже не знакомо.

     
     
  • 5.51, анонн (ok), 22:23, 05/10/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    О, в лучших традициях опеннета пошли отмазки Т е ты не знаешь, что такое хвос... большой текст свёрнут, показать
     
     
  • 6.58, Урри (ok), 23:15, 05/10/2021 [^] [^^] [^^^] [ответить]  
  • –6 +/
    Слив, как говорится, засчитан.

    Вместо подтверждения своих слов решением простейшей задачи аноним с криками "балаболка сломалась, ничего не вижу, бабабаба" убежал в кусты.

    Впрочем, это было ожидаемо, ибо вы не умеете ничего решать, вы умеете только звездеть на форуме, ни уха ни хвоста не понимая в темах.

     
     
  • 7.60, анонн (ok), 23:37, 05/10/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > Урри сел в лужу с "gcc это (tail-call optimization) вроде как уже 20 лет умеет"
    > Урри сел в лужу с хвостовой рекурсией
    > Урри важно надул щечки и сделал вид принимающего грязевую ванну
    > Слив, как говорится, засчитан.

    Засчитан, засчитан. Ты главное, не огорчайся - ничего иного я от тебя уже и не ожидал.
    > Впрочем, это было ожидаемо, ибо вы не умеете ничего решать, вы умеете только звездеть на форуме, ни уха ни хвоста не понимая в темах.

    Ты полностью раскрыл свое "понимание" темы своим же "примером". И походу даже сейчас до тебя не дошло, _что_ там не так.
    >> чем отличается _возможная_ tail call оптимизация от _гарантированной_?
    >> tail call оптимизация
    > оптимизируй
    > (x * recursion(x-2, n-1) * (n + recursion(x+2, n-1));

    ---
    https://wiki.haskell.org/Tail_recursion
    > A recursive function is tail recursive if the final result of the recursive call is the final result of the function itself. If the result of the recursive call must be further processed (say, by adding 1 to it, or consing another element onto the beginning of it), it is not tail recursive.
    >  Here is formal definition of "tail recursive". ...
    >

     
     
  • 8.61, Урри (ok), 23:43, 05/10/2021 [^] [^^] [^^^] [ответить]  
  • –3 +/
    нэт это не хвостовая рекурсия еще варианты Как видим в луже сейчас барахтаетс... текст свёрнут, показать
     
     
  • 9.62, анонн (ok), 00:02, 06/10/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Конечно же нет - это же твой п 821 о 821 п 821 ы 821 т 821 к 821 а 821 ... текст свёрнут, показать
     
  • 9.66, Аноним (1), 00:30, 06/10/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Ты вот мне обьясни, зачем ты троллиреешь из под акка Ведь априори все понимают,... текст свёрнут, показать
     
     
  • 10.67, Ordu (ok), 00:36, 06/10/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Это нынче называется троллингом Кек, я всегда любил троллей, а теперь просто об... текст свёрнут, показать
     
     
  • 11.86, Аноним (1), 23:29, 06/10/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Троллинг тупостью Есть такое ... текст свёрнут, показать
     
  • 5.73, n00by (ok), 07:50, 06/10/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Вот листинг, к которому относится комментарий code ADDVN ... большой текст свёрнут, показать
     
     
  • 6.87, n00by (ok), 07:35, 07/10/2021 [^] [^^] [^^^] [ответить]  
  • +/
    По поводу push rax смотрим AMD64 ABI Draft 1.0

    3.2.2 The Stack Frame

    "the value (%rsp + 8) is always a multiple of 16 (32 or 64) when control is transferred to the function entry point."

    Требование обусловлено возможным сохранением в стеке 128-битных регистров (xmm).

    Т.о. команда дополняет 6 предыдущих push, с учётом сохранения rip на стеке при call имеем выровненный указатель (насколько оправдано следовать требованиям, когда копилятор видит определение вызываемой функции, где отсутствует запись в стек 128-битных данных -- другой вопрос).


    По поводу "add rsp, 8" смотрим 64-ia-32-architectures-optimization-manual.pdf

    3.4.2.6 Optimization for Decoded ICache

    Assembly/Compiler Coding Rule 25. (M impact, M generality) Avoid putting explicit references to
    ESP in a sequence of stack operations (POP, PUSH, CALL, RET).

    Правило исключать явное обращение к указателю стека из последовательностей push обусловлено в

    2.4.2.4 Micro-op Queue and the Loop Stream Detector (LSD)

    The Loop Stream Detector (LSD)
    ...
    Cannot have mismatched stack operations. For example, more PUSH than POP instructions.

    Вопрос по "add rsp, 8" открыт.

     

  • 1.63, Andrey_Karpov (ok), 00:09, 06/10/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Да, да, уже проанализировал с помощью PVS-Studio. Наслаждаюсь опечатками в коде LLVM. Пример:

    bool operator==(const BDVState &Other) const {
      return OriginalValue == OriginalValue && BaseValue == Other.BaseValue &&
        Status == Other.Status;
    }

    Пишу статью.

     
     
  • 2.76, Аноним (76), 09:12, 06/10/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Очень ждем! Всегда вас плюсую. Вы такой молодец!
     
  • 2.94, burjui (ok), 06:32, 08/10/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Выше в треде кто-то ёрничал в духе "нужно переписать на Rust" (по другому поводу), только прикол в том, что clippy эту ошибку отлавливает:

    struct X {
        a: usize,
        b: usize,
    }

    impl PartialEq for X {
        fn eq(&self, other: &Self) -> bool {
            self.a == self.a && self.b == other.b
        }
    }

    error: equal expressions as operands to '=='
      --> src/main.rs:12:9
       |
    12 |         self.a == self.a && self.b == other.b
       |         ^^^^^^^^^^^^^^^^
       |
       = note: '#[deny(clippy::eq_op)]' on by default
       = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#eq_op

    Кто не в курсе, clippy поставляется с тулчейном.

    Я ни к чему не призываю, тем более к переписыванию LLVM на Rust (упаси боже). Просто хотел поделиться достижениями прогресса и отметить профессионализм разработчиков, которые умудрились написать не только самый полезный компилятор (безотносительно ЯП), но и приличный статический анализатор в довесок.

     
     
  • 3.98, burjui (ok), 17:11, 08/10/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Тут был ответ на мой комментарий (удалён):

    >>Я ни к чему не призываю, тем более к переписыванию LLVM на Rust (упаси боже).
    >Ты же растаман! Почему ты ёрничаешь?

    Я не ёрничаю, просто понимаю, что переписать миллионы строк кода на любой ЯП - мало того, что очень трудозатратно, но вдобавок чревато внесением туевой хучи новых багов, чего мне категорически не хотелось бы видеть в компиляторах, использующих LLVM. Тоже относится к перписыванию Linux.

     
  • 3.106, Аноним (106), 12:48, 11/10/2021 [^] [^^] [^^^] [ответить]  
  • +/
    ./test.cpp:6:16: warning: self-comparison always evaluates to true [-Wtautological-compare]
                    return value == value && value == other.value;
     

  • 1.75, Аноним (75), 08:39, 06/10/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Я прошу прощения, за сообщение не совсем по теме новости.  У clang есть документация (PDF, просто как страницы в Интернете)?  Не "обрезанный" user's manual https://clang.llvm.org/docs/UsersManual.html, а что-то подобное документации GCC?
     
     
  • 2.89, Аноним (89), 09:34, 07/10/2021 [^] [^^] [^^^] [ответить]  
  • +/
    https://clang.llvm.org/docs/ - все что есть. Как в gcc чтобы - нет, такого нету.
     
  • 2.92, Аноним (-), 05:54, 08/10/2021 [^] [^^] [^^^] [ответить]  
  • +/
    "Код открытый, но корпорасты не хотят чтобы вы его легко изучили". Вот весь и ответ.
     
     
  • 3.95, Аноним (1), 12:33, 08/10/2021 [^] [^^] [^^^] [ответить]  
  • +/
    А чего тут не хватило?
    https://clang.llvm.org/docs/
     
     
  • 4.105, Аноним (105), 22:59, 09/10/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Сравните, например, описание -march и -mtune в документации GCC и в https://clang.llvm.org/docs/.  Или описание -W{...} опций.
     

  • 1.99, Andrey_Karpov (ok), 22:45, 08/10/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А вот и обещанная статья: Выявляем ошибки в релизе LLVM 13.0.0 - https://pvs-studio.com/ru/blog/posts/cpp/0871/
     
     
  • 2.102, Прохожий (??), 14:06, 09/10/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Скажите, пожалуйста, вы собираетесь сообщать о найденных ошибках сообществу? Или эта статья была только в целях PR вашего продукта?
    Понимаю, что вы ничего никому не должны, просто любопытствую.
    Спасибо.
     
     
  • 3.104, Andrey_Karpov (ok), 16:43, 09/10/2021 [^] [^^] [^^^] [ответить]  
  • +/
    https://bugs.llvm.org/show_bug.cgi?id=52120
     

  • 1.101, qwerty (??), 11:24, 09/10/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    А где-то еще llvm используется, окромя шланга?
     
     
  • 2.103, Прохожий (??), 14:08, 09/10/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Тебя в Гугле забанили? Или от природы такой "сообразительный"?

    На вот. https://en.wikipedia.org/wiki/LLVM

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:
    При перепечатке указание ссылки на opennet.ru обязательно



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

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