The OpenNET Project / Index page

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



"Релиз набора компиляторов LLVM 13.0"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Релиз набора компиляторов LLVM 13.0"  +/
Сообщение от opennews (??), 05-Окт-21, 12:04 
После шести месяцев разработки представлен релиз проекта LLVM 13.0 - GCC-совместимого инструментария (компиляторы, оптимизаторы и генераторы кода), компилирующего программы в промежуточный биткод RISC-подобных виртуальных инструкций (низкоуровневая виртуальная машина с многоуровневой системой оптимизаций). Сгенерированный псевдокод может быть преобразован при помощи JIT-компилятора в машинные инструкции непосредственно в момент выполнения программы...

Подробнее: https://www.opennet.ru/opennews/art.shtml?num=55898

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по времени | RSS]


1. "Релиз набора компиляторов LLVM 13.0"  +1 +/
Сообщение от Аноним (1), 05-Окт-21, 12:04 
Супер! Молодцы!
Ответить | Правка | Наверх | Cообщить модератору

2. "Релиз набора компиляторов LLVM 13.0"  +/
Сообщение от Аноним (1), 05-Окт-21, 12:05 
Ждем во фряшечке. Вот и свежий зен подвезли.
Ответить | Правка | Наверх | Cообщить модератору

10. "Релиз набора компиляторов LLVM 13.0"  –2 +/
Сообщение от Аноним (1), 05-Окт-21, 12:59 
Проверил. В портах уже добавили.
Ответить | Правка | Наверх | Cообщить модератору

20. "Релиз набора компиляторов LLVM 13.0"  –1 +/
Сообщение от анонн (ok), 05-Окт-21, 14:24 
> Проверил. В портах уже добавили.

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


Ответить | Правка | Наверх | Cообщить модератору

32. "Релиз набора компиляторов LLVM 13.0"  –1 +/
Сообщение от Аноним (1), 05-Окт-21, 17:00 
Точно. Со слепу просмотрел. Спасибо!
Ответить | Правка | Наверх | Cообщить модератору

91. "Релиз набора компиляторов LLVM 13.0"  +/
Сообщение от Аноним (1), 08-Окт-21, 01:49 
Теперича таки в портах.
Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

38. "Релиз набора компиляторов LLVM 13.0"  +/
Сообщение от Ivan_83 (ok), 05-Окт-21, 18:04 
В портах само по себе не сильно интересно, интереснее когда затащат в базу и когда для месы начнут юзать.
Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

39. "Релиз набора компиляторов LLVM 13.0"  +/
Сообщение от Аноним (1), 05-Окт-21, 18:13 
Согласен. Но с чего-то надо начинать...
Ответить | Правка | Наверх | Cообщить модератору

3. "Релиз набора компиляторов LLVM 13.0"  +/
Сообщение от Аноним (3), 05-Окт-21, 12:07 
судя по номеру таки production ready
Ответить | Правка | Наверх | Cообщить модератору

4. "Релиз набора компиляторов LLVM 13.0"  –1 +/
Сообщение от Аноним (4), 05-Окт-21, 12:08 
Почему он так долго компи лируется начиная с 12? Судя по логу ощущение что он зависает часов на 20, но это не так и нужно ждать.
Ответить | Правка | Наверх | Cообщить модератору

5. "Релиз набора компиляторов LLVM 13.0"  –11 +/
Сообщение от QwertyReg (ok), 05-Окт-21, 12:11 
Или надо просто выкинуть свой Pentium 4 и компилировать на современном железе.
Ответить | Правка | Наверх | Cообщить модератору

6. "Релиз набора компиляторов LLVM 13.0"  +/
Сообщение от Аноним (4), 05-Окт-21, 12:13 
> Или надо просто выкинуть свой Pentium 4 и компилировать на современном железе.

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

Ответить | Правка | Наверх | Cообщить модератору

7. "Релиз набора компиляторов LLVM 13.0"  +2 +/
Сообщение от Аноним (4), 05-Окт-21, 12:16 
Я посмотрел, 16 часов против 50 минут.
Ответить | Правка | Наверх | Cообщить модератору

8. "Релиз набора компиляторов LLVM 13.0"  +6 +/
Сообщение от Аноним (8), 05-Окт-21, 12:37 
Пора переписывать на Rust.
Ответить | Правка | Наверх | Cообщить модератору

11. "Релиз набора компиляторов LLVM 13.0"  +/
Сообщение от Аноним (1), 05-Окт-21, 13:00 
Это ты со сборками линуксов перепктал. В бсдях все православно. Патриархально. Профессура шалить не дает.
Ответить | Правка | Наверх | Cообщить модератору

14. "Релиз набора компиляторов LLVM 13.0"  +/
Сообщение от Аноним (8), 05-Окт-21, 13:16 
И что, в БЗДях ещё не вкатили Rust?
Ответить | Правка | Наверх | Cообщить модератору

15. "Релиз набора компиляторов LLVM 13.0"  –2 +/
Сообщение от Аноним (1), 05-Окт-21, 13:27 
Как в линуксе? Неее.
Ответить | Правка | Наверх | Cообщить модератору

80. "Релиз набора компиляторов LLVM 13.0"  –1 +/
Сообщение от malloc (?), 06-Окт-21, 09:39 
Они там неосиляторы. Все как один - профессора.
Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

93. "Релиз набора компиляторов LLVM 13.0"  +/
Сообщение от burjui (ok), 08-Окт-21, 06:02 
Чтобы компилилось так же или ещё дольше.
Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

22. "Релиз набора компиляторов LLVM 13.0"  +2 +/
Сообщение от еуые (?), 05-Окт-21, 14:34 
Это явно баг, но если вы об этом не сообщие в их багзилу https://llvm.org/docs/HowToSubmitABug.html то никто об этом не узнает и не исправит.
Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

23. "Релиз набора компиляторов LLVM 13.0"  –1 +/
Сообщение от Попандопала (?), 05-Окт-21, 14:48 
Тут советовали включать USE="pgo" вдруг поможет. Сейчас синкну и посмотрю. Ешё ccache есть,но я его не осилил.(
Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

24. "Релиз набора компиляторов LLVM 13.0"  –1 +/
Сообщение от Попандопала (?), 05-Окт-21, 15:05 
2021-08-24T10:07:01 >>> sys-devel/llvm: 4 hours, 31 minutes, 59 seconds
Ответить | Правка | Наверх | Cообщить модератору

25. "Релиз набора компиляторов LLVM 13.0"  –1 +/
Сообщение от Попандопала (?), 05-Окт-21, 15:13 
2021-08-24T10:07:01 >>> sys-devel/llvm-12.0.1: 4 hours, 31 minutes, 59 seconds
Не тот.(
Ответить | Правка | Наверх | Cообщить модератору

45. "Релиз набора компиляторов LLVM 13.0"  +1 +/
Сообщение от Попандопала (?), 05-Окт-21, 19:33 
2021-08-24T10:07:01 >>> sys-devel/llvm-12.0.1: 4 hours, 31 minutes, 59 seconds
2021-10-05T15:10:42 >>> sys-devel/llvm-13.0.0: 4 hours, 5 minutes, 29 seconds
Ответить | Правка | Наверх | Cообщить модератору

48. "Релиз набора компиляторов LLVM 13.0"  –1 +/
Сообщение от Аноним (4), 05-Окт-21, 21:37 
> 2021-08-24T10:07:01 >>> sys-devel/llvm-12.0.1: 4 hours, 31 minutes, 59 seconds
> 2021-10-05T15:10:42 >>> sys-devel/llvm-13.0.0: 4 hours, 5 minutes, 29 seconds

Так llvm  у меня полчаса компилируется. А вот шланг…

Ответить | Правка | Наверх | Cообщить модератору

77. "Релиз набора компиляторов LLVM 13.0"  –1 +/
Сообщение от Попандопала (?), 06-Окт-21, 09:23 
2021-07-10T21:20:55 >>> sys-devel/clang-12.0.1: 1 hour, 11 minutes, 32 seconds
2021-10-06T04:47:40 >>> sys-devel/clang-13.0.0: 4 hours, 24 minutes, 36 seconds

2021-08-23T14:38:16 >>> dev-lang/rust-1.54.0: 6 hours, 4 minutes, 37 seconds
26 seconds2021-09-30T13:39:08 >>> dev-lang/rust-1.55.0: 5 hours, 32 minutes, 20 seconds

Ответить | Правка | Наверх | Cообщить модератору

43. "Релиз набора компиляторов LLVM 13.0"  +2 +/
Сообщение от n00by (ok), 05-Окт-21, 19:24 
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 (или где будет кеш).

Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

46. "Релиз набора компиляторов LLVM 13.0"  –1 +/
Сообщение от Попандопала (?), 05-Окт-21, 19:35 
Для ГСС этот флаг им же и собирается. ЛЛВМ не все может собрать.
Ответить | Правка | Наверх | Cообщить модератору

74. "Релиз набора компиляторов LLVM 13.0"  +/
Сообщение от n00by (ok), 06-Окт-21, 08:08 
Имею ввиду, что в ebuild для llvm USE-флаг pdo отсуствует. То есть он ничего не даёт.

$ grep -A1 IUSE /var/db/repos/gentoo/sys-devel/llvm/llvm-13.0.0.ebuild
IUSE="debug doc exegesis gold libedit +libffi ncurses test xar xml z3
    kernel_Darwin"

Ответить | Правка | Наверх | Cообщить модератору

78. "Релиз набора компиляторов LLVM 13.0"  +/
Сообщение от Попандопала (?), 06-Окт-21, 09:28 
Как я понимаю этот флаг создает некий профиль и потом компилит изменения при следующей компиляции если компилить с ГСС. Тот же ЛЛВМ тоже будет собираться быстрее.
Ответить | Правка | Наверх | Cообщить модератору

83. "Релиз набора компиляторов LLVM 13.0"  +/
Сообщение от n00by (ok), 06-Окт-21, 14:08 
А, теперь понял, что имелось ввиду. Да, Вы правы. Если GCC собрать с PGO, он будет собирать быстрее. Но ускорение не в разы.
Ответить | Правка | Наверх | Cообщить модератору

40. "Релиз набора компиляторов LLVM 13.0"  –1 +/
Сообщение от Ordu (ok), 05-Окт-21, 18:27 
Я бы предположил, что у тебя оперативка кончилась, и процесс сборки начал свопиться. Хотя, конечно, это гадание на кофейной гуще.
Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

56. "Релиз набора компиляторов LLVM 13.0"  –1 +/
Сообщение от Аноним (4), 05-Окт-21, 23:01 
Вполне возможно, но нет никакой дисковой активности и висит 1 процесс по 10+ часов -- вывод никак не меняется. Попробовал уполовинить число потоков, стало ощутимо дольше.
Ответить | Правка | Наверх | Cообщить модератору

64. "Релиз набора компиляторов LLVM 13.0"  –1 +/
Сообщение от Ordu (ok), 06-Окт-21, 00:25 
Вон у меня сейчас как раз, "по счастливому совпадению", собирается llvm-13. Вот как раз когда я писал эти строки, он мергался в систему из билд-диры. Сложно оценить сколько именно он собирался, потому что время я не засекал, даже не знаю точно когда он начал собираться, просто пару часов назад я видел его где-то в начале сборки (там две фазы сборки, первая ~1000 объектов собирает, вторая под 2k, вот где-то в середине первой фазы я видел), и потом ещё отправлял его поспать на некоторое время, пока я поиграюсь в игрушку на сон грядущий. Но, думаю, не больше двух часов. На железе 10+ летней давности. С жёсткого диска, не с SSD. И я не замечал за ним, чтобы он резко увеличивал время сборки на какой-то версии, впрочем, опять же, я не следил -- emerge что-то там собирает, я лишь примерно оцениваю общее время сборки с точностью плюс-минус лапоть, а время сборки индивидуальных пакетов оцениваю методом "интуитивный Монте-Карло": чем чаще я вижу, что emerge собирает какой-то пакет, тем дольше значит он собирается.

Скорее всего, это какая-то особенность твоей системы, но чтобы хотя бы предположить какая -- нужна информация о том, что происходит. Чем больше, тем лучше. Что за 1 процесс? clang? lld? Загрузка процессора 100%? Какого типа загрузка -- user, sys, iowait?  Опции сборки, флаги компилятору какие-то передаёшь? Мне не хочется продолжать гадать на кофейной гуще.

Ответить | Правка | Наверх | Cообщить модератору

68. "Релиз набора компиляторов LLVM 13.0"  –1 +/
Сообщение от Аноним (4), 06-Окт-21, 00:42 
Со сборкой llvm у меня проблем нет, сопоставимо с gcc по веремени. У меня проблема со сборкой clang. И rust тоже слишком долго компилируется.
Ответить | Правка | Наверх | Cообщить модератору

69. "Релиз набора компиляторов LLVM 13.0"  –1 +/
Сообщение от Аноним (4), 06-Окт-21, 00:43 
Хотя не, gcc 15 минут и llvm 60 минут, в 4 раза медленнее выходит.
Ответить | Правка | Наверх | Cообщить модератору

70. "Релиз набора компиляторов LLVM 13.0"  –1 +/
Сообщение от Аноним (4), 06-Окт-21, 00:44 
От 40 до 60.
Ответить | Правка | Наверх | Cообщить модератору

71. "Релиз набора компиляторов LLVM 13.0"  +/
Сообщение от Ordu (ok), 06-Окт-21, 01:21 
Ну я могу лишь посочувствовать.
Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

72. "Релиз набора компиляторов LLVM 13.0"  +1 +/
Сообщение от n00by (ok), 06-Окт-21, 07:27 
> Сложно оценить сколько именно он собирался, потому что время
> я не засекал, даже не знаю точно когда он начал собираться

Можно посмотреть

qlop llvm

это из app-portage/portage-utils

Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

79. "Релиз набора компиляторов LLVM 13.0"  +2 +/
Сообщение от Попандопала (?), 06-Окт-21, 09:30 
qlop -vHt rust
Так с версией покажет.
Ответить | Правка | Наверх | Cообщить модератору

90. "Релиз набора компиляторов LLVM 13.0"  +/
Сообщение от Ordu (ok), 08-Окт-21, 01:11 
Забавно. Не знал про такое. Два с половиной часа для всех с 9 по 13 версию, отдельные выбросы до трёх -- это скорее всего я останавливал его сборку зачем-то.
Ответить | Правка | К родителю #72 | Наверх | Cообщить модератору

18. "Релиз набора компиляторов LLVM 13.0"  –4 +/
Сообщение от Аноним (18), 05-Окт-21, 14:09 
Нужно закрыть хлебало, прежде чем указывать людям, что им выкинуть, а что нет. Как оплатишь разработку и производство процессора под их нужды и подаришь им его бесплатно - так сразу и выкинут.
Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

21. "Релиз набора компиляторов LLVM 13.0"  –2 +/
Сообщение от QwertyReg (ok), 05-Окт-21, 14:28 
Это СПО - делаешь сам, на чистом энтузиазме. Какие деньги?
Ответить | Правка | Наверх | Cообщить модератору

27. "Релиз набора компиляторов LLVM 13.0"  +/
Сообщение от Аноним (27), 05-Окт-21, 15:44 
В ссылку тебя надо с такими комментариями.
Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

9. "Релиз набора компиляторов LLVM 13.0"  +/
Сообщение от Аноним (9), 05-Окт-21, 12:59 
Вспоминаю как на своей макоси собирал 11 версию (в Homebrew тогда бинарник ещё не завезли). Эта вещь пять часов компилировалась и из-за этого чуть не опоздал на работу.
Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

12. "Релиз набора компиляторов LLVM 13.0"  +2 +/
Сообщение от Аноним (1), 05-Окт-21, 13:02 
Ты так говоришь, как буд-то в длительном конпелянии что-то плозое. Ты можешь откинуться на спинку стула и медитировать, глядя на пробегающие по экрану символы. Представлять, как буд-то и земля и небо все состоит из них.
Ответить | Правка | Наверх | Cообщить модератору

16. "Релиз набора компиляторов LLVM 13.0"  +1 +/
Сообщение от BorichL (ok), 05-Окт-21, 13:44 
А он под все доступные архитектуры собирается или только под нужные?
Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

30. "Релиз набора компиляторов LLVM 13.0"  +1 +/
Сообщение от pavlinux (ok), 05-Окт-21, 16:34 
> ... или только под нужные?

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

Ответить | Правка | Наверх | Cообщить модератору

34. "Релиз набора компиляторов LLVM 13.0"  +/
Сообщение от Аноним (34), 05-Окт-21, 17:09 
Ну это-то явное дно. Как можно без PDP-11?
Ответить | Правка | Наверх | Cообщить модератору

36. "Релиз набора компиляторов LLVM 13.0"  +1 +/
Сообщение от pavlinux (ok), 05-Окт-21, 17:19 
>  Как можно без PDP-11?

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


Ответить | Правка | Наверх | Cообщить модератору

13. "Релиз набора компиляторов LLVM 13.0"  –7 +/
Сообщение от Аноним (13), 05-Окт-21, 13:03 
Есть такая проблема подтверждаю , но приходится выбирать "собирается дольше , но после ui летает" или "собирается по олд стандартной модели быстро собирается , но позже собранная библиотека хуже и тормознее работает" , но есть идея пере собрать сами компиляторы C++20 с помощью C++2a или C++2b и вернуть в олд стандарт по причине сборки в общем никто не говорил что будет легко , а как известно в россии то уж тем более это не работает тут все хотят только деньги получать при том сразу и не работать т.е не заниматься пере сборкой пере меинфреимом
Ответить | Правка | Наверх | Cообщить модератору

19. "Релиз набора компиляторов LLVM 13.0"  +1 +/
Сообщение от zramemail (?), 05-Окт-21, 14:19 
Ебилды уже есть. Идёт собирать...
Ответить | Правка | Наверх | Cообщить модератору

26. "Релиз набора компиляторов LLVM 13.0"  –1 +/
Сообщение от Аноним (27), 05-Окт-21, 15:42 
Отлично проделанная работа. Долгих лет проекту.
Ответить | Правка | Наверх | Cообщить модератору

29. "Релиз набора компиляторов LLVM 13.0"  +/
Сообщение от pavlinux (ok), 05-Окт-21, 16:11 
> __attribute__((musttail)) ...

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

Ответить | Правка | Наверх | Cообщить модератору

31. "Релиз набора компиляторов LLVM 13.0"  +1 +/
Сообщение от Урри (ok), 05-Окт-21, 16:53 
gcc это (tail-call optimization) вроде как уже 20 лет умеет, без всяких там __attribute__.

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

Ответить | Правка | Наверх | Cообщить модератору

35. "Релиз набора компиляторов LLVM 13.0"  +/
Сообщение от pavlinux (ok), 05-Окт-21, 17:16 
> gcc это (tail-call optimization) вроде как уже 20 лет умеет

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

Ответить | Правка | Наверх | Cообщить модератору

37. "Релиз набора компиляторов LLVM 13.0"  –1 +/
Сообщение от Урри (ok), 05-Окт-21, 17:32 
Ну да - про ллвм, который научился с костылями делать то, что можно было научиться делать давным-давно и без костылей.
Ответить | Правка | Наверх | Cообщить модератору

42. "Релиз набора компиляторов LLVM 13.0"  +2 +/
Сообщение от Ordu (ok), 05-Окт-21, 18:36 
Знаток в треде?

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

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

Ответить | Правка | Наверх | Cообщить модератору

50. "Релиз набора компиляторов LLVM 13.0"  –1 +/
Сообщение от Урри (ok), 05-Окт-21, 21:57 
> Атрибут 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;
}

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

Ответить | Правка | Наверх | Cообщить модератору

52. "Релиз набора компиляторов LLVM 13.0"  +/
Сообщение от Ordu (ok), 05-Окт-21, 22:28 
Ты ворвался в тред с обвинениями llvm в том, что он такую полезную фичу запилил только сейчас. Но теперь, ты доказываешь, что фича бесполезная. Либо фича полезная, и тогда ты сейчас несёшь бред. Либо фича бесполезная, и тогда ты бред нёс раньше.
Ответить | Правка | Наверх | Cообщить модератору

59. "Релиз набора компиляторов LLVM 13.0"  –2 +/
Сообщение от Урри (ok), 05-Окт-21, 23:35 
Нет. Я угораю со знатоков, которые радуются, что шланг научился из любой рекурсии делать хвостовую.
Ответить | Правка | Наверх | Cообщить модератору

65. "Релиз набора компиляторов LLVM 13.0"  +1 +/
Сообщение от Ordu (ok), 06-Окт-21, 00:27 
> Нет. Я угораю со знатоков, которые радуются, что шланг научился из любой
> рекурсии делать хвостовую.

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

Ответить | Правка | Наверх | Cообщить модератору

54. "Релиз набора компиляторов LLVM 13.0"  +/
Сообщение от Аноним (-), 05-Окт-21, 22:41 
>> tail-call оптимизацию обязательной.
>     int r = x * recursion(x-2, n-1);
>     int q = n + recursion(x+2, n-1);
>     return q * r;
> Оптимизируй "обязательно".

/0

Ответить | Правка | К родителю #50 | Наверх | Cообщить модератору

57. "Релиз набора компиляторов LLVM 13.0"  –2 +/
Сообщение от Урри (ok), 05-Окт-21, 23:13 
Нэт. Оно работает и не 0 - проверить минута времени.
Ответить | Правка | Наверх | Cообщить модератору

81. "Релиз набора компиляторов LLVM 13.0"  +/
Сообщение от Аноним (-), 06-Окт-21, 13:01 
> Нэт. Оно работает и не 0 - проверить минута времени.

Прочитать, что такое tail-call и перестать пороть чушь - тоже минута времени.


Ответить | Правка | Наверх | Cообщить модератору

84. "Релиз набора компиляторов LLVM 13.0"  –1 +/
Сообщение от Урри (ok), 06-Окт-21, 18:05 
Еще один аноним прибежал преобразовывать функцию в обязательную хвостовую рекурсию?
Ну милости прошу, ждем решение.
Ответить | Правка | Наверх | Cообщить модератору

85. "Релиз набора компиляторов LLVM 13.0"  +/
Сообщение от Аноним (-), 06-Окт-21, 20:37 

>> Реализована поддержка гарантированных хвостовых вызовов (вызов подпрограммы в самом конце функции, образующий хвостовую рекурсию в случае, если подпрограмма вызывается саму себя). Поддержка гарантированных хвостовых вызовов обеспечена при помощи атрибута "[[clang::musttail]]" в C++ и "__attribute__((musttail))" в C, применяемых в выражении "return". Возможность позволяет реализовать оптимизации через развёртывание кода в плоскую итерацию для экономии расходования стека.

***
>> Calls marked musttail must obey the following additional rules:
>> The call must immediately precede a ret instruction, or a pointer bitcast followed by a ret instruction.
>> The ret instruction must return the (possibly bitcasted) value produced by the call, undef, or void.
>> The calling conventions of the caller and callee must match.

***
> Еще один аноним прибежал преобразовывать функцию в обязательную хвостовую рекурсию?

Расскажи, в каких именно буковках ты сумел углядеть "преобразовывать функцию в обязательную хвостовую рекурсию"?

Ответить | Правка | Наверх | Cообщить модератору

47. "Релиз набора компиляторов LLVM 13.0"  –1 +/
Сообщение от анонн (ok), 05-Окт-21, 20:46 
>> _гарантированных_ хвостовых вызовов
>> 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).
>

Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

49. "Релиз набора компиляторов LLVM 13.0"  –3 +/
Сообщение от Урри (ok), 05-Окт-21, 21:55 
> чем отличается _возможная_ 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-i...

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

---
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.

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

Ответить | Правка | Наверх | Cообщить модератору

51. "Релиз набора компиляторов LLVM 13.0"  +2 +/
Сообщение от анонн (ok), 05-Окт-21, 22:23 
>> чем отличается _возможная_ tail call оптимизация от _гарантированной_?
> Оу, даже гарантированной? Ого, какие новые интересные глубины открывают анонимы опеннета.
> А не оптимизирует ли гарантированно уважаемый гуру вот такую простую рекурсию?

О, в лучших традициях опеннета пошли отмазки.
> int r = x * recursion(x-2, n-1);
> int q = n + recursion(x+2, n-1);
> return q * r;

Т.е. ты не знаешь, что такое хвостовая рекурсия. Отлично.

>>> gcc это (tail-call optimization) вроде как уже 20 лет умеет, без всяких там __attribute__.
>> https://www.mail-archive.com/gcc@gcc.gnu.org/msg95265.html
>> Would it be feasible to implement a "musttail" statement attribute in GCC to get a guarantee that tail call optimization will be performed?
> Сам по ссылке ходил то, аноним? Или нагуглил первое, не глядя тыкнул и "смааатрите, какой я Тузик, ой, Герой!"

Сказать-то что хотел, клоун?

> Ссылка: https://blog.reverberate.org/2021/04/21/musttail-efficient-i...
> An exciting feature just landed in the main branch of the Clang compiler. Using the
> [[clang::musttail]] or __attribute__((musttail)) statement attributes, you can now get
> guaranteed tail calls in C, C++, and Objective-C.

То ли ты и эту ссылку не читал, то ли это такой неуклюжий спрыг ...

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

Эк ты ловко пропустил
> Tail call optimization is not even new to Clang: like GCC and many other compilers, Clang was
> already capable of optimizing tail calls. In fact, the musttail attribute in our first example
> above did not change the output of the compiler at all: Clang would already have optimized the
> tail call under -O2.
> What is new is the guarantee. While compilers will often optimize tail calls successfully, this is best-effort, not something you can rely on

и
> I very much hope that the attribute will catch on, spreading to GCC,

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

Экий ты самокритичный.
Ну и ладно: эта балаболка сломалась, вносите следующую!

Ответить | Правка | Наверх | Cообщить модератору

58. "Релиз набора компиляторов LLVM 13.0"  –6 +/
Сообщение от Урри (ok), 05-Окт-21, 23:15 
Слив, как говорится, засчитан.

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

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

Ответить | Правка | Наверх | Cообщить модератору

60. "Релиз набора компиляторов LLVM 13.0"  +/
Сообщение от анонн (ok), 05-Окт-21, 23:37 
> Урри сел в лужу с "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". ...
>

Ответить | Правка | Наверх | Cообщить модератору

61. "Релиз набора компиляторов LLVM 13.0"  –3 +/
Сообщение от Урри (ok), 05-Окт-21, 23:43 
> (x * recursion(x-2, n-1) * (n + recursion(x+2, n-1));

нэт. это не хвостовая рекурсия.
еще варианты?

> Урри сел в лужу с хвостовой рекурсией

Как видим в луже сейчас барахтается анонн, но всем вопит что он не он.
Если что, то Урри уже 20 лет пишет рекурсии на лиспе и отлично знает как и что надо делать.

Ответить | Правка | Наверх | Cообщить модератору

62. "Релиз набора компиляторов LLVM 13.0"  +1 +/
Сообщение от анонн (ok), 06-Окт-21, 00:02 
>>> tail call оптимизация
>> оптимизируй
>> (x * recursion(x-2, n-1) * (n + recursion(x+2, n-1));
> нэт. это не хвостовая рекурсия.

Конечно же нет - это же твой п̵о̵п̵ы̵т̵к̵а̵ ̵н̵е̵у̵к̵л̵ю̵ж̵е̵г̵о̵ ̵с̵п̵р̵ы̵г̵а̵ "пример". Сам же цитировал "tail call оптимизация" и сам же предложил "А не оптимизирует ли" ... "это не хвостовая рекурсия".
То ли старческий маразм, то ли не менее классическое опеннетное "прочитал жопой, сам себе что-то придумал, сам себе что-то подтвердил, сам себе надул щечки".
> Если что, то Урри уже 20 лет рассказывает на опеннете, что пишет рекурсии на лиспе

Никто и не сомневался в подвешенности твоего языка/пальцев, умения юлить и нести с умным видом бред.


Ответить | Правка | Наверх | Cообщить модератору

66. "Релиз набора компиляторов LLVM 13.0"  +/
Сообщение от Аноним (1), 06-Окт-21, 00:30 
Ты вот мне обьясни, зачем ты троллиреешь из под акка? Ведь априори все понимают, что ты пгосто шуткуешь:)
Ответить | Правка | К родителю #61 | Наверх | Cообщить модератору

67. "Релиз набора компиляторов LLVM 13.0"  +/
Сообщение от Ordu (ok), 06-Окт-21, 00:36 
> Ты вот мне обьясни, зачем ты троллиреешь из под акка? Ведь априори
> все понимают, что ты пгосто шуткуешь:)

Это нынче называется троллингом? Кек, я всегда любил троллей, а теперь просто обожаю. Люблю когда люди в разговоре со мной выглядят тупыми как пробка, но если они делают это намеренно, чтобы сделать приятно мне, то это вызывает чувство благодарности.

Ответить | Правка | Наверх | Cообщить модератору

86. "Релиз набора компиляторов LLVM 13.0"  +/
Сообщение от Аноним (1), 06-Окт-21, 23:29 
Троллинг тупостью. Есть такое.
Ответить | Правка | Наверх | Cообщить модератору

73. "Релиз набора компиляторов LLVM 13.0"  +/
Сообщение от n00by (ok), 06-Окт-21, 07:50 
> Ссылка: https://blog.reverberate.org/2021/04/21/musttail-efficient-i...
> Большой разбор и в конце цитата:
> ---
> 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.
> ---

Вот листинг, к которому относится комментарий


ADDVN:                                  # @ADDVN
        push    rbp
        push    r15
        push    r14
        push    r13
        push    r12
        push    rbx
        push    rax
        mov     r15, r9
        mov     r14, r8
        mov     rbx, rcx
        mov     r12, rsi
        mov     ebp, edi
        movzx   eax, dh
        cmp     dword ptr [r9 + 8*rax + 4], -12
        jae     .LBB0_1
.LBB0_2:
        movzx   eax, dl
        movsd   xmm0, qword ptr [r14 + 8*rax]   # xmm0 = mem[0],zero
        mov     eax, ebp
        addsd   xmm0, qword ptr [r15 + 8*rax]
        movsd   qword ptr [r15 + 8*rax], xmm0
        mov     edx, dword ptr [rbx]
        add     rbx, 4
        movzx   eax, dl
        movzx   edi, dh
        shr     edx, 16
        mov     rax, qword ptr [r12 + 8*rax]
        mov     rsi, r12
        mov     rcx, rbx
        mov     r8, r14
        mov     r9, r15
        add     rsp, 8
        pop     rbx
        pop     r12
        pop     r13
        pop     r14
        pop     r15
        pop     rbp
        jmp     rax                             # TAILCALL
.LBB0_1:
        mov     edi, ebp
        mov     rsi, r12
        mov     r13d, edx
        mov     rcx, rbx
        mov     r8, r14
        mov     r9, r15
        call    fallback
        mov     edx, r13d
        jmp     .LBB0_2

"a lot of data spills to the stack" вижу (конвенция обязывает сохранить регистры из строк с rbp ... rbx; допустимо ли было это оптимизировать без inline подстановки вызываемой функции fallback или стоило перенести за метку .LBB0_1 - другой вопрос).

"a stack frame" не вижу.

RBP используется как регистр общего назначения (mov  ebp, edi).
Единственная операция с указателем стека (add rsp, 8) компенсирует push rax из 8-й строки.
В связи с последним возникает вопрос: на кой пихать аккумулятор в стек, если значение не нужно?
Что-то не то с этим кодом. Возможно, недоделка оптимизатора, или баг.

Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

87. "Релиз набора компиляторов LLVM 13.0"  +/
Сообщение от n00by (ok), 07-Окт-21, 07:35 
По поводу 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" открыт.

Ответить | Правка | Наверх | Cообщить модератору

63. "Релиз набора компиляторов LLVM 13.0"  +4 +/
Сообщение от Andrey_Karpov (ok), 06-Окт-21, 00:09 
Да, да, уже проанализировал с помощью PVS-Studio. Наслаждаюсь опечатками в коде LLVM. Пример:

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

Пишу статью.

Ответить | Правка | Наверх | Cообщить модератору

76. "Релиз набора компиляторов LLVM 13.0"  +2 +/
Сообщение от Аноним (76), 06-Окт-21, 09:12 
Очень ждем! Всегда вас плюсую. Вы такой молодец!
Ответить | Правка | Наверх | Cообщить модератору

94. "Релиз набора компиляторов LLVM 13.0"  +1 +/
Сообщение от burjui (ok), 08-Окт-21, 06:32 
Выше в треде кто-то ёрничал в духе "нужно переписать на 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 (упаси боже). Просто хотел поделиться достижениями прогресса и отметить профессионализм разработчиков, которые умудрились написать не только самый полезный компилятор (безотносительно ЯП), но и приличный статический анализатор в довесок.

Ответить | Правка | К родителю #63 | Наверх | Cообщить модератору

98. "Релиз набора компиляторов LLVM 13.0"  +/
Сообщение от burjui (ok), 08-Окт-21, 17:11 
Тут был ответ на мой комментарий (удалён):

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

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

Ответить | Правка | Наверх | Cообщить модератору

106. "Релиз набора компиляторов LLVM 13.0"  +/
Сообщение от Аноним (106), 11-Окт-21, 12:48 
./test.cpp:6:16: warning: self-comparison always evaluates to true [-Wtautological-compare]
                return value == value && value == other.value;
Ответить | Правка | К родителю #94 | Наверх | Cообщить модератору

75. "Релиз набора компиляторов LLVM 13.0"  +2 +/
Сообщение от Аноним (75), 06-Окт-21, 08:39 
Я прошу прощения, за сообщение не совсем по теме новости.  У clang есть документация (PDF, просто как страницы в Интернете)?  Не "обрезанный" user's manual https://clang.llvm.org/docs/UsersManual.html, а что-то подобное документации GCC?
Ответить | Правка | Наверх | Cообщить модератору

89. "Релиз набора компиляторов LLVM 13.0"  +/
Сообщение от Аноним (89), 07-Окт-21, 09:34 
https://clang.llvm.org/docs/ - все что есть. Как в gcc чтобы - нет, такого нету.
Ответить | Правка | Наверх | Cообщить модератору

92. "Релиз набора компиляторов LLVM 13.0"  +/
Сообщение от Аноним (-), 08-Окт-21, 05:54 
"Код открытый, но корпорасты не хотят чтобы вы его легко изучили". Вот весь и ответ.
Ответить | Правка | К родителю #75 | Наверх | Cообщить модератору

95. "Релиз набора компиляторов LLVM 13.0"  +/
Сообщение от Аноним (1), 08-Окт-21, 12:33 
А чего тут не хватило?
https://clang.llvm.org/docs/
Ответить | Правка | Наверх | Cообщить модератору

105. "Релиз набора компиляторов LLVM 13.0"  +1 +/
Сообщение от Аноним (105), 09-Окт-21, 22:59 
Сравните, например, описание -march и -mtune в документации GCC и в https://clang.llvm.org/docs/.  Или описание -W{...} опций.
Ответить | Правка | Наверх | Cообщить модератору

99. "Релиз набора компиляторов LLVM 13.0"  +/
Сообщение от Andrey_Karpov (ok), 08-Окт-21, 22:45 
А вот и обещанная статья: Выявляем ошибки в релизе LLVM 13.0.0 - https://pvs-studio.com/ru/blog/posts/cpp/0871/
Ответить | Правка | Наверх | Cообщить модератору

102. "Релиз набора компиляторов LLVM 13.0"  –1 +/
Сообщение от Прохожий (??), 09-Окт-21, 14:06 
Скажите, пожалуйста, вы собираетесь сообщать о найденных ошибках сообществу? Или эта статья была только в целях PR вашего продукта?
Понимаю, что вы ничего никому не должны, просто любопытствую.
Спасибо.
Ответить | Правка | Наверх | Cообщить модератору

104. "Релиз набора компиляторов LLVM 13.0"  +/
Сообщение от Andrey_Karpov (ok), 09-Окт-21, 16:43 
https://bugs.llvm.org/show_bug.cgi?id=52120
Ответить | Правка | Наверх | Cообщить модератору

101. "Релиз набора компиляторов LLVM 13.0"  –1 +/
Сообщение от qwertyemail (??), 09-Окт-21, 11:24 
А где-то еще llvm используется, окромя шланга?
Ответить | Правка | Наверх | Cообщить модератору

103. "Релиз набора компиляторов LLVM 13.0"  +/
Сообщение от Прохожий (??), 09-Окт-21, 14:08 
Тебя в Гугле забанили? Или от природы такой "сообразительный"?

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

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




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

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