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

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

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

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

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

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

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

7. Сообщение от Аноним (4), 05-Окт-21, 12:16	+2 +/–
Я посмотрел, 16 часов против 50 минут.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #8, #22, #23, #40

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

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

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

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

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

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

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

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

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

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

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

20. Сообщение от анонн (ok), 05-Окт-21, 14:24	–1 +/–
> Проверил. В портах уже добавили. Нет. В портах - все еще RC4.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #32, #91

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

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

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

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

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

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

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

29. Сообщение от pavlinux (ok), 05-Окт-21, 16:11	+/–
> __attribute__((musttail)) ... Вот сейчас хорошо было
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #31

30. Сообщение от pavlinux (ok), 05-Окт-21, 16:34	+1 +/–
> ... или только под нужные? PDP-11 не поддерживает :(((
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #34

31. Сообщение от Урри (ok), 05-Окт-21, 16:53	+1 +/–
gcc это (tail-call optimization) вроде как уже 20 лет умеет, без всяких там __attribute__. Вот сейчас проверил, 4.1.2 точно оптимизирует. А версии ниже у меня под руками нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #35, #47

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

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

35. Сообщение от pavlinux (ok), 05-Окт-21, 17:16	+/–
> gcc это (tail-call optimization) вроде как уже 20 лет умеет Так новость вроде про LLVM
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #37

36. Сообщение от pavlinux (ok), 05-Окт-21, 17:19	+1 +/–
>  Как можно без PDP-11? Плохо  без них, сильные программисты больше не нужны.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34

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

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

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

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

42. Сообщение от Ordu (ok), 05-Окт-21, 18:36	+2 +/–
Знаток в треде? llvm выполнял tail-call оптимизации столько, сколько я с ним имел дело. Но, tail-call оптимизация -- это то, что компилятор может делать, может не делать. Как минимум, на его решение оптимизировать или нет влияет заказанный уровень оптимизации. Возможно влияет что-то ещё, тут я не скажу. Атрибут musttail, что в gcc, что в llvm, делает tail-call оптимизацию обязательной. На любом уровне оптимизаций, даже на -O0. Предположу, что этот атрибут нужен для тех случаев, когда код, написанный в функциональном стиле, рекурсией обрабатывает огромные массивы, и из-за этого в debug-сборках переполняет все разумные размеры стека.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #50

43. Сообщение от n00by (ok), 05-Окт-21, 19:24	+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 (или где будет кеш).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #46

45. Сообщение от Попандопала (?), 05-Окт-21, 19:33	+1 +/–
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ообщить модератору
Родитель: #25 Ответы: #48

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

47. Сообщение от анонн (ok), 05-Окт-21, 20:46	–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). >
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #49

48. Сообщение от Аноним (4), 05-Окт-21, 21:37	–1 +/–
> 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ообщить модератору
Родитель: #45 Ответы: #77

49. Сообщение от Урри (ok), 05-Окт-21, 21:55	–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-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ообщить модератору
Родитель: #47 Ответы: #51, #73

50. Сообщение от Урри (ok), 05-Окт-21, 21:57	–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; } Оптимизируй "обязательно".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #52, #54

51. Сообщение от анонн (ok), 05-Окт-21, 22:23	+2 +/–
>> чем отличается _возможная_ 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ообщить модератору
Родитель: #49 Ответы: #58

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

54. Сообщение от Аноним (-), 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
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50 Ответы: #57

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

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

58. Сообщение от Урри (ok), 05-Окт-21, 23:15	–6 +/–
Слив, как говорится, засчитан. Вместо подтверждения своих слов решением простейшей задачи аноним с криками "балаболка сломалась, ничего не вижу, бабабаба" убежал в кусты. Впрочем, это было ожидаемо, ибо вы не умеете ничего решать, вы умеете только звездеть на форуме, ни уха ни хвоста не понимая в темах.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51 Ответы: #60

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

60. Сообщение от анонн (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ообщить модератору
Родитель: #58 Ответы: #61

61. Сообщение от Урри (ok), 05-Окт-21, 23:43	–3 +/–
> (x * recursion(x-2, n-1) * (n + recursion(x+2, n-1)); нэт. это не хвостовая рекурсия. еще варианты? > Урри сел в лужу с хвостовой рекурсией Как видим в луже сейчас барахтается анонн, но всем вопит что он не он. Если что, то Урри уже 20 лет пишет рекурсии на лиспе и отлично знает как и что надо делать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60 Ответы: #62, #66

62. Сообщение от анонн (ok), 06-Окт-21, 00:02	+1 +/–
>>> tail call оптимизация >> оптимизируй >> (x * recursion(x-2, n-1) * (n + recursion(x+2, n-1)); > нэт. это не хвостовая рекурсия. Конечно же нет - это же твой п̵о̵п̵ы̵т̵к̵а̵ ̵н̵е̵у̵к̵л̵ю̵ж̵е̵г̵о̵ ̵с̵п̵р̵ы̵г̵а̵ "пример". Сам же цитировал "tail call оптимизация" и сам же предложил "А не оптимизирует ли" ... "это не хвостовая рекурсия". То ли старческий маразм, то ли не менее классическое опеннетное "прочитал жопой, сам себе что-то придумал, сам себе что-то подтвердил, сам себе надул щечки". > Если что, то Урри уже 20 лет рассказывает на опеннете, что пишет рекурсии на лиспе Никто и не сомневался в подвешенности твоего языка/пальцев, умения юлить и нести с умным видом бред.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #61

63. Сообщение от Andrey_Karpov (ok), 06-Окт-21, 00:09	+4 +/–
Да, да, уже проанализировал с помощью PVS-Studio. Наслаждаюсь опечатками в коде LLVM. Пример: bool operator==(const BDVState &Other) const {   return OriginalValue == OriginalValue && BaseValue == Other.BaseValue &&     Status == Other.Status; } Пишу статью.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #76, #94

64. Сообщение от Ordu (ok), 06-Окт-21, 00:25	–1 +/–
Вон у меня сейчас как раз, "по счастливому совпадению", собирается llvm-13. Вот как раз когда я писал эти строки, он мергался в систему из билд-диры. Сложно оценить сколько именно он собирался, потому что время я не засекал, даже не знаю точно когда он начал собираться, просто пару часов назад я видел его где-то в начале сборки (там две фазы сборки, первая ~1000 объектов собирает, вторая под 2k, вот где-то в середине первой фазы я видел), и потом ещё отправлял его поспать на некоторое время, пока я поиграюсь в игрушку на сон грядущий. Но, думаю, не больше двух часов. На железе 10+ летней давности. С жёсткого диска, не с SSD. И я не замечал за ним, чтобы он резко увеличивал время сборки на какой-то версии, впрочем, опять же, я не следил -- emerge что-то там собирает, я лишь примерно оцениваю общее время сборки с точностью плюс-минус лапоть, а время сборки индивидуальных пакетов оцениваю методом "интуитивный Монте-Карло": чем чаще я вижу, что emerge собирает какой-то пакет, тем дольше значит он собирается. Скорее всего, это какая-то особенность твоей системы, но чтобы хотя бы предположить какая -- нужна информация о том, что происходит. Чем больше, тем лучше. Что за 1 процесс? clang? lld? Загрузка процессора 100%? Какого типа загрузка -- user, sys, iowait?  Опции сборки, флаги компилятору какие-то передаёшь? Мне не хочется продолжать гадать на кофейной гуще.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #68, #72

65. Сообщение от Ordu (ok), 06-Окт-21, 00:27	+1 +/–
> Нет. Я угораю со знатоков, которые радуются, что шланг научился из любой > рекурсии делать хвостовую. Сам придумал, приписал другим, сам порадовался находке. Зачем парился писать об этом? Ты о каждой мастурбации своей тоже отчитываешься в рандомных уголках интернета?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59

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

67. Сообщение от Ordu (ok), 06-Окт-21, 00:36	+/–
> Ты вот мне обьясни, зачем ты троллиреешь из под акка? Ведь априори > все понимают, что ты пгосто шуткуешь:) Это нынче называется троллингом? Кек, я всегда любил троллей, а теперь просто обожаю. Люблю когда люди в разговоре со мной выглядят тупыми как пробка, но если они делают это намеренно, чтобы сделать приятно мне, то это вызывает чувство благодарности.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66 Ответы: #86

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

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

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

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

72. Сообщение от n00by (ok), 06-Окт-21, 07:27	+1 +/–
> Сложно оценить сколько именно он собирался, потому что время > я не засекал, даже не знаю точно когда он начал собираться Можно посмотреть qlop llvm это из app-portage/portage-utils
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64 Ответы: #79, #90

73. Сообщение от 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-й строки. В связи с последним возникает вопрос: на кой пихать аккумулятор в стек, если значение не нужно? Что-то не то с этим кодом. Возможно, недоделка оптимизатора, или баг.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49 Ответы: #87

74. Сообщение от 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ообщить модератору
Родитель: #46 Ответы: #78

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

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

77. Сообщение от Попандопала (?), 06-Окт-21, 09:23	–1 +/–
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ообщить модератору
Родитель: #48

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

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

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

81. Сообщение от Аноним (-), 06-Окт-21, 13:01	+/–
> Нэт. Оно работает и не 0 - проверить минута времени. Прочитать, что такое tail-call и перестать пороть чушь - тоже минута времени.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57 Ответы: #84

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

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

85. Сообщение от Аноним (-), 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ообщить модератору
Родитель: #84

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

87. Сообщение от 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ообщить модератору
Родитель: #73

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

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

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

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

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

94. Сообщение от burjui (ok), 08-Окт-21, 06:32	+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 (упаси боже). Просто хотел поделиться достижениями прогресса и отметить профессионализм разработчиков, которые умудрились написать не только самый полезный компилятор (безотносительно ЯП), но и приличный статический анализатор в довесок.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63 Ответы: #98, #106

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

98. Сообщение от burjui (ok), 08-Окт-21, 17:11	+/–
Тут был ответ на мой комментарий (удалён): >>Я ни к чему не призываю, тем более к переписыванию LLVM на Rust (упаси боже). >Ты же растаман! Почему ты ёрничаешь? Я не ёрничаю, просто понимаю, что переписать миллионы строк кода на любой ЯП - мало того, что очень трудозатратно, но вдобавок чревато внесением туевой хучи новых багов, чего мне категорически не хотелось бы видеть в компиляторах, использующих LLVM. Тоже относится к перписыванию Linux.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94

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

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

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

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

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

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

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

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

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