forum.opennet.ru - "Релиз набора компиляторов LLVM 11.0 " (85)

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

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

"Релиз набора компиляторов LLVM 11.0 "	+2 +/–
Сообщение от opennews (??), 12-Окт-20, 22:53
После шести месяцев разработки представлен релиз проекта LLVM 11.0 - GCC-совместимого инструментария (компиляторы, оптимизаторы и генераторы кода), компилирующего программы в промежуточный биткод RISC-подобных виртуальных инструкций (низкоуровневая виртуальная машина с многоуровневой системой оптимизаций). Сгенерированный псевдокод может быть преобразован при помощи JIT-компилятора в машинные инструкции непосредственно в момент выполнения программы... Подробнее: https://www.opennet.me/opennews/art.shtml?num=53874
Ответить \| Правка \| Cообщить модератору

Оглавление

Нужно, не копайте, Аноним (1), 22:53 , 12-Окт-20, (1) +4
Для чего Fortran использовать можно, кроме вычислений А то ощущение, что язык п, Аноним (3), 23:01 , 12-Окт-20, (3) –8

А зачем нужен фортран, если есть C, C , OpenCL, SyCL, а если и их мало, то Boos, Аноним (5), 23:12 , 12-Окт-20, (5) –10

Зачем библиотеки перечислять , Аноним (3), 23:26 , 12-Окт-20, (6) +3

Потому что без них BLAS оптимизированные операции линейной алгебры, вроде скаля, Аноним (5), 23:31 , 12-Окт-20, (7) +3
Чтобы показать, что он про них читал , YetAnotherOnanym (ok), 09:45 , 13-Окт-20, (36) +7

Патамушта это все не для людей,это все для погроммистов, чюдо ты наше , Gefest (?), 20:21 , 13-Окт-20, (62) –1

Fortran вечен , Я (??), 23:44 , 12-Окт-20, (10) +4

Можно на нём операционную систему написать или микроконтроллеры прогать , Аноним (3), 23:54 , 12-Окт-20, (12) –3

Я под ВЭБ на нем прогаю, вместо жаваскрипта Олдскульненько так , Аноним (15), 00:16 , 13-Окт-20, (15) +6

блин, я аж пивом подавился когда распарсил , ksjdjfgklsjdklgfj (?), 08:29 , 13-Окт-20, (33) +4

Можно ли молотком хлеб порезать или полы подмести , ИмяХ (?), 11:22 , 13-Окт-20, (39) –1

Некорректное сравнение , Аноним (3), 12:25 , 13-Окт-20, (47) +1
Заморозь в форме ножа, желательно хлебного как пила чтобы лезвие было Мойка в, Аноним (80), 11:45 , 16-Окт-20, (80)

Для повышения чсв разве что , Аноним (18), 00:48 , 13-Окт-20, (18) –3
Ни для чего В llvm он нужен только для поддежрки кое-какого распространнного ле, Аноним (19), 01:05 , 13-Окт-20, (19) –13

Уровень опеннетовских анонимных экспертов порой просто поражает , Аноним (65), 02:01 , 14-Окт-20, (65) +5

Да, он изначально заточен и его продолжают затачивать прежде всего под цели вычи, yep (?), 07:06 , 13-Окт-20, (26) +5
Это язык для физиков и математиков, а не для программистов Нахрен им его ещё дл, nobody (??), 11:02 , 13-Окт-20, (37)

а вам все готовое подавай пс не подскажите каким языком пользуются макаки , Sw00p aka Jerom (?), 11:14 , 13-Окт-20, (38) –2

AppleScript, Zlo (??), 11:53 , 13-Окт-20, (44) +3

А как же Haskell Разве не Haskell язык для математиков , fsb4000 (?), 17:10 , 14-Окт-20, (72)

Фортран это почти ассемблер с человеческим лицом Что-то сложное типа БД на нем , Аноним (51), 13:51 , 13-Окт-20, (51)

А грёбанный долгоиграющий баг с неправильными флагами компоновки при использован, Аноним (5), 23:05 , 12-Окт-20, (4)

А можно чуть поподробнее, пожалуйста Интересно , Аноним (40), 11:36 , 13-Окт-20, (40)

Можно https github com pocl pocl blob master cmake clangLinkerWorkaround shhtt, Аноним (5), 10:25 , 14-Окт-20, (68)

Юзай GCC , Аноним (-), 13:39 , 13-Окт-20, (49) –2

1 Большая деградация производительности 2 Требует SSE2 , Аноним (5), 23:41 , 12-Окт-20, (8) +2

Который есть во всех х64 процессорах Что сказать-то хотел , Аноним (13), 00:02 , 13-Окт-20, (13) +5

В aarch64 этого набора инструкций нет А сказать я хотел, что есть люди которы, Аноним (5), 00:30 , 13-Окт-20, (16) +4

Скрыто модератором, Аноним (19), 01:10 , 13-Окт-20, (20)

Скрыто модератором, Аноним (5), 07:40 , 13-Окт-20, (28) –2

Скрыто модератором, ksjdjfgklsjdklgfj (?), 08:30 , 13-Окт-20, (34) –1

Скрыто модератором, Аноним (5), 08:38 , 13-Окт-20, (35) –1

К сожалению, в обществе этот закон прекрасно работает, Fracta1L (ok), 07:28 , 13-Окт-20, (27)

Не, в обществе ты толкнёшь кого-то вниз, сам полетишь наверх, но всё общество це, Аноним (5), 07:42 , 13-Окт-20, (29)

Но им-то - наплевать Самому взобраться на броневичок над остальными рабами гораз, пох. (?), 11:53 , 13-Окт-20, (43) –1

хорошо ты Ленина мазанул, на корзину печенья и банку варенья заработал , Аноним (46), 12:22 , 13-Окт-20, (46)

Но я броневик хочу Печенье и варенье потом сам реквизирую, у недобитых плохишей, пох. (?), 16:35 , 13-Окт-20, (55)
Это где выдают Кроме троцкистких недобитков никто пропагандой сейчас не занима, Аноним (79), 11:25 , 16-Окт-20, (79)

3 Необязательна -mno-lvi-cfi -mno-lvi-hardening , topin89 (ok), 23:17 , 13-Окт-20, (63)

Есть нюанс - требует либо пересборки софта очень долго и ресурсоёмко в случае F, Аноним (5), 10:30 , 14-Окт-20, (69) +1

Зато PIC несколько лет назад выпилили Теперь лифтинг делать некуда и натравлива, Аноним (5), 23:43 , 12-Окт-20, (9)
А толку Их всё равно кроме Visual Studio ни одна система сборки не использует , Аноним (5), 23:46 , 12-Окт-20, (11)

Cmake, нет , Имя (?), 02:48 , 13-Окт-20, (22) +1

И внезапно visual studio так же может использовать clang llvm , Аноним (23), 05:18 , 13-Окт-20, (23)

Не спорю, я и GCC прикручивал к студии, VS это только среда А вы говорите про M, Имя (?), 05:20 , 13-Окт-20, (24)

Спасибо, значит уже добавили Помню, как мне пришлось их из кода выпиливать, ког, Аноним (5), 07:45 , 13-Окт-20, (30)

debug-info в отдельном файле -- это удобно Можно хоть всю систему собрать с отл, Ordu (ok), 16:20 , 13-Окт-20, (54) –1

Это вообще не та штука И objcopy для этой цели используется примерно во всех би, Аноним (60), 19:57 , 13-Окт-20, (60)

С таким прогрессом впору GCC именовать LLVM-совместимым , zzz (??), 00:13 , 13-Окт-20, (14) –5
С поддержкой Cortex-A77 как-то протормозили , Андрей (??), 01:33 , 13-Окт-20, (21)
Ненужно GCC по всем параметрам уделывает LLVM, Иваня (?), 06:44 , 13-Окт-20, (25) –5

Возможно, что зависит от программы, архитектуры, для которой соберается, и от ка, Аноним (5), 08:04 , 13-Окт-20, (31)

ошибка, для native дельта вообще 9 миллисекунд, но у native время больше, чем, н, Аноним (5), 08:09 , 13-Окт-20, (32)
кто-то кого-то порвал Сам тест сколько миллисекунд длился , Аноним (42), 11:43 , 13-Окт-20, (42) +1

100500, Аноним (45), 12:19 , 13-Окт-20, (45) –1
https github com KOLANICH research_compiler_optimizations_comparison tree mast, Аноним (5), 10:36 , 14-Окт-20, (70)

Влажность мечт 146 , Аноним (41), 11:37 , 13-Окт-20, (41)

Исследовал тему, более чем, 9-й и тем более 10-й GCC именно что уделывает Пару л, erthink (ok), 13:02 , 13-Окт-20, (48) +1

И зря Ты не знаешь как начинался проект LLVM Изначально разработчики тупо скоп, Аноним (-), 13:47 , 13-Окт-20, (50) –2

Минус что llvm уже существует и второй не нужен, Аноним (51), 13:59 , 13-Окт-20, (52) –1
А они о том, что вернулись , знают o_O code cat hello c gcc hello c -fdump, Аноним84701 (ok), 14:24 , 13-Окт-20, (53) +1

gt оверквотинг удален А что это -fdump-final-insns выводит внутреннее предста, n00by (ok), 17:00 , 13-Окт-20, (57)

Дык, Register Transfer Language DI тут кстати Double Integer mode represent, Аноним84701 (ok), 18:42 , 13-Окт-20, (58)

То есть язык, описывающий машинные инструкции целевой платформы В общем-то и, n00by (ok), 07:45 , 14-Окт-20, (66)

И зачем здесь демонстрировать свое невежество , Sem (??), 01:38 , 14-Окт-20, (64)

Интересно, что оптимизаторы определяют семантику высокоуровнего кода, но есть ра, n00by (ok), 16:44 , 13-Окт-20, (56)

Скорее всего спекуляция , потому что на этапе промежуточного кода gimple оно , Аноним84701 (ok), 19:16 , 13-Окт-20, (59) +2

test edi, edi mov edx, 0 cmove eax, edxЕсли о спекулятивном и, n00by (ok), 08:06 , 14-Окт-20, (67)

Да нет, это я так спекулирую в смысле, с умным видом рассуждаю Примерно да h, Аноним84701 (ok), 12:15 , 14-Окт-20, (71) +2

Так быстрее, хотя можно поспорить о том стоит ли игра свеч Насколько помню, вари, erthink (ok), 19:54 , 14-Окт-20, (73)

Про быстрее при 0 я писал https www opennet ru openforum vsluhforumID3 122094 , n00by (ok), 11:04 , 15-Окт-20, (74)

Там четыре варианта в зависимости от целевого ядра Поиграйтесь флагом -march на , erthink (ok), 23:28 , 15-Окт-20, (77)

Так варианты машинного кода не объясняют причину, почему выбрана именно такая В, n00by (ok), 13:07 , 16-Окт-20, (81)

Ну как-бы очевидно что компилятор руководствуется подобными правилами, которые б, erthink (ok), 15:45 , 16-Окт-20, (82)

Так вопрос в том, насколько эти правила адекватны железу Когда-то мне приходило, n00by (ok), 17:55 , 17-Окт-20, (84)
Проверил гипотезу так объявил задействованные функции как static inline включил , n00by (ok), 08:38 , 18-Окт-20, (85)

Как насчёт pgo Все эти ручные твики на редкость не универсальны А сам компилят, Аноним (87), 10:51 , 21-Окт-20, (87)

В данном конкретном случае Clang безо всяких твиков выполнил во время трансля, n00by (ok), 12:44 , 21-Окт-20, (88)

Вот когда по удобству кросс-компиляции уделает, тогда приходи со своим экспертны, Аноним (60), 19:58 , 13-Окт-20, (61) –3

Человек-снежинка , erthink (ok), 23:30 , 15-Окт-20, (78)

n00by, erthink, Аноним84701 - втроём полнедели обсуждали обсуждали да таки ничег, Аноним (83), 17:49 , 17-Окт-20, (83) –1

Ну да, я не понял, какое отношение имеет оптимизация графа вызовов когда оптими, n00by (ok), 08:46 , 18-Окт-20, (86)

Не мог пройти мимо и не потыкать палочкой Проверка Clang 11 с помощью PVS-Stud, Andrey_Karpov (ok), 15:03 , 27-Окт-20, (89)

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

1. "Релиз набора компиляторов LLVM 11.0 " +4 +/–

Сообщение от Аноним (1), 12-Окт-20, 22:53

Нужно, не копайте

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

3. "Релиз набора компиляторов LLVM 11.0 " –8 +/–

Сообщение от Аноним (3), 12-Окт-20, 23:01

Для чего Fortran использовать можно, кроме вычислений? А то ощущение, что язык под одну нишу заточен.

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

5. "Релиз набора компиляторов LLVM 11.0 " –10 +/–

Сообщение от Аноним (5), 12-Окт-20, 23:12

А зачем нужен фортран, если есть C, C++, OpenCL, SyCL, а если и их мало, то Boost::Compute (по сути просто обёртка вокруг OpenCL для человечной инициализации), ArrayFire, а если и этого мало, то pyTorch, TensorFlow, MxNet, и даже недавний релиз NeoML от ABBYY, с зависимостями от проприетарной платной bloatare, дискриминирующей против AMD, Intel Performance Primitives.

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

6. "Релиз набора компиляторов LLVM 11.0 " +3 +/–

Сообщение от Аноним (3), 12-Окт-20, 23:26

Зачем библиотеки перечислять?

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

7. "Релиз набора компиляторов LLVM 11.0 " +3 +/–

Сообщение от Аноним (5), 12-Окт-20, 23:31

Потому что без них BLAS (оптимизированные операции линейной алгебры, вроде скалярного произведения и разложений, причём каждой операции по несколько видов, в зависимости от симметрии матрицы) из коробки нет. Ещё AMD OpenCL BLAS и FFT забыл перечислить.

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

36. "Релиз набора компиляторов LLVM 11.0 " +7 +/–

Сообщение от YetAnotherOnanym (ok), 13-Окт-20, 09:45

Чтобы показать, что он про них читал.

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

62. "Релиз набора компиляторов LLVM 11.0 " –1 +/–

Сообщение от Gefest (?), 13-Окт-20, 20:21

Патамушта это все не для людей,это все для погроммистов, чюдо ты наше.

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

10. "Релиз набора компиляторов LLVM 11.0 " +4 +/–

Сообщение от Я (??), 12-Окт-20, 23:44

Fortran вечен!!!

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

12. "Релиз набора компиляторов LLVM 11.0 " –3 +/–

Сообщение от Аноним (3), 12-Окт-20, 23:54

Можно на нём операционную систему написать или микроконтроллеры прогать?

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

15. "Релиз набора компиляторов LLVM 11.0 " +6 +/–

Сообщение от Аноним (15), 13-Окт-20, 00:16

Я под ВЭБ на нем прогаю, вместо жаваскрипта. Олдскульненько так.

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

33. "Релиз набора компиляторов LLVM 11.0 " +4 +/–

Сообщение от ksjdjfgklsjdklgfj (?), 13-Окт-20, 08:29

блин, я аж пивом подавился когда распарсил :)

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

39. "Релиз набора компиляторов LLVM 11.0 " –1 +/–

Сообщение от ИмяХ (?), 13-Окт-20, 11:22

Можно ли молотком хлеб порезать или полы подмести?

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

47. "Релиз набора компиляторов LLVM 11.0 " +1 +/–

Сообщение от Аноним (3), 13-Окт-20, 12:25

Некорректное сравнение.

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

80. "Релиз набора компиляторов LLVM 11.0 " +/–

Сообщение от Аноним (80), 16-Окт-20, 11:45

Заморозь в форме ножа, желательно хлебного (как пила чтобы лезвие было); Мойка высокого давления и направленной струёй вжух, вжух

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

18. "Релиз набора компиляторов LLVM 11.0 " –3 +/–

Сообщение от Аноним (18), 13-Окт-20, 00:48

>Для чего Fortran использовать можно, кроме вычислений?
Для повышения чсв разве что.

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

19. "Релиз набора компиляторов LLVM 11.0 " –13 +/–

Сообщение от Аноним (19), 13-Окт-20, 01:05

Ни для чего. В llvm он нужен только для поддежрки кое-какого распространнного легаси на этом г-не написанного, чтобы исключить необходимость в gfortran, который тащит gcc и прочий несовместимый мусор.

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

65. "Релиз набора компиляторов LLVM 11.0 " +5 +/–

Сообщение от Аноним (65), 14-Окт-20, 02:01

Уровень опеннетовских анонимных экспертов порой просто поражает.

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

26. "Релиз набора компиляторов LLVM 11.0 " +5 +/–

Сообщение от yep (?), 13-Окт-20, 07:06

Да, он изначально заточен и его продолжают затачивать прежде всего под цели вычислений.

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

37. "Релиз набора компиляторов LLVM 11.0 " +/–

Сообщение от nobody (??), 13-Окт-20, 11:02

Это язык для физиков и математиков, а не для программистов. Нахрен им его ещё для чего-то использовать?

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

38. "Релиз набора компиляторов LLVM 11.0 " –2 +/–

Сообщение от Sw00p aka Jerom (?), 13-Окт-20, 11:14

а вам все готовое подавай?
пс: не подскажите каким языком пользуются "макаки"?

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

44. "Релиз набора компиляторов LLVM 11.0 " +3 +/–

Сообщение от Zlo (??), 13-Окт-20, 11:53

AppleScript

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

72. "Релиз набора компиляторов LLVM 11.0 " +/–

Сообщение от fsb4000 (?), 14-Окт-20, 17:10

А как же Haskell? Разве не Haskell язык для математиков?

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

51. "Релиз набора компиляторов LLVM 11.0 " +/–

Сообщение от Аноним (51), 13-Окт-20, 13:51

Фортран это почти ассемблер с человеческим лицом. Что-то сложное типа БД на нем делать боль.

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

4. "Релиз набора компиляторов LLVM 11.0 " +/–

Сообщение от Аноним (5), 12-Окт-20, 23:05

А грёбанный долгоиграющий баг с неправильными флагами компоновки при использовании стандартной библиотеки glibc при включённом positional-independent code при использовании clang в качестве фронтенда линкера так и не пофиксили. Приходится изращаться для обхода.

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

40. "Релиз набора компиляторов LLVM 11.0 " +/–

Сообщение от Аноним (40), 13-Окт-20, 11:36

А можно чуть поподробнее, пожалуйста? Интересно.

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

68. "Релиз набора компиляторов LLVM 11.0 " +/–

Сообщение от Аноним (5), 14-Окт-20, 10:25

Можно.
https://github.com/pocl/pocl/blob/master/cmake/clangLinkerWo...
https://bugs.llvm.org/show_bug.cgi?id=44594

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

49. "Релиз набора компиляторов LLVM 11.0 " –2 +/–

Сообщение от Аноним (-), 13-Окт-20, 13:39

Юзай GCC!

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

8. "Релиз набора компиляторов LLVM 11.0 " +2 +/–

Сообщение от Аноним (5), 12-Окт-20, 23:41

>Добавлена защита от атак LVI (Load Value Injection)
1. Большая деградация производительности.
2. Требует SSE2.

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

13. "Релиз набора компиляторов LLVM 11.0 " +5 +/–

Сообщение от Аноним (13), 13-Окт-20, 00:02

>Требует SSE2
Который есть во всех х64 процессорах. Что сказать-то хотел?

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

16. "Релиз набора компиляторов LLVM 11.0 " +4 +/–

Сообщение от Аноним (5), 13-Окт-20, 00:30

>Который есть во всех х64 процессорах
В aarch64 этого набора инструкций нет ;)
А сказать я хотел, что есть люди (которые даже софт не собирают, только на форумах - ****ят), которым очень не терпится прибить 32-бита, а вернее не столько прибить 32-бита, сколько нагадить его пользователям, при этом прикрывшись другими мотивами. Если кого-то толкнуть вниз, сам полетишь вверх - им кажется. Не понимают, что в обществе закон сохранения импульса не работает.

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

20. Скрыто модератором +/–

Сообщение от Аноним (19), 13-Окт-20, 01:10

> а вернее не столько прибить 32-бита, сколько нагадить его пользователям
Нихрена себе у старьёвщиков кукуха поехала, дошло уже до теории заговоров, а эго раздулось просто непомерно. Вообще конечно вам надо не просто гадить, а с вами надо целенаправленно воевать, потому что вы вредите человечеству огромным числом способов, начиная с экосистемы СПО, оттягивая на себя ресурсы мантейнеров, тестировщиков и билдферм и заканчивая экологией, сжирая своим гнилым железом на порядок больше электричества чем нужно для выполнения вычислительных задач которые оно еле тужится вытянуть. Но нет, никто вам не гадит, вас просто никто не рассматривает всерьёз.

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

28. Скрыто модератором –2 +/–

Сообщение от Аноним (5), 13-Окт-20, 07:40

Годный потребитель порвался.
P.S. Кукушка не едет, она прилетает ;)
P.P.S. Я сам категорически против цензуры, но вам может быть необходимо знать следующее:
> КоАП РФ Статья 20.3.1. Возбуждение ненависти либо вражды, а равно унижение человеческого достоинства
> Действия, направленные на возбуждение ненависти либо вражды, а также на унижение достоинства человека либо группы лиц по признакам пола, расы, национальности, языка, происхождения, отношения к религии, а равно принадлежности к какой-либо социальной группе, совершенные публично, в том числе с использованием средств массовой информации либо информационно-телекоммуникационных сетей, включая сеть "Интернет", если эти действия не содержат уголовно наказуемого деяния, влекут наложение административного штрафа на граждан в размере от десяти тысяч до двадцати тысяч рублей, или обязательные работы на срок до ста часов, или административный арест на срок до пятнадцати суток; на юридических лиц - от двухсот пятидесяти тысяч до пятисот тысяч рублей.
> УК РФ Статья 282. Возбуждение ненависти либо вражды, а равно унижение человеческого достоинства
> 1. Действия, направленные на возбуждение ненависти либо вражды, а также на унижение достоинства человека либо группы лиц по признакам пола, расы, национальности, языка, происхождения, отношения к религии, а равно принадлежности к какой-либо социальной группе, совершенные публично, в том числе с использованием средств массовой информации либо информационно-телекоммуникационных сетей, включая сеть "Интернет", лицом после его привлечения к административной ответственности за аналогичное деяние в течение одного года, наказываются штрафом в размере от трехсот тысяч до пятисот тысяч рублей или в размере заработной платы или иного дохода осужденного за период от двух до трех лет, либо принудительными работами на срок от одного года до четырех лет с лишением права занимать определенные должности или заниматься определенной деятельностью на срок до трех лет, либо лишением свободы на срок от двух до пяти лет.
> УК РФ Статья 354. Публичные призывы к развязыванию агрессивной войны
> Публичные призывы к развязыванию агрессивной войны наказываются штрафом в размере до трехсот тысяч рублей или в размере заработной платы или иного дохода осужденного за период до двух лет либо лишением свободы на срок до трех лет.

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

34. Скрыто модератором –1 +/–

Сообщение от ksjdjfgklsjdklgfj (?), 13-Окт-20, 08:30

а вот и кремлеботы подтянулись

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

35. Скрыто модератором –1 +/–

Сообщение от Аноним (5), 13-Окт-20, 08:38

Кремлеботы - за цензуру.

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

27. "Релиз набора компиляторов LLVM 11.0 " +/–

Сообщение от Fracta1L (ok), 13-Окт-20, 07:28

> Если кого-то толкнуть вниз, сам полетишь вверх - им кажется. Не понимают, что в обществе закон сохранения импульса не работает.
К сожалению, в обществе этот закон прекрасно работает

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

29. "Релиз набора компиляторов LLVM 11.0 " +/–

Сообщение от Аноним (5), 13-Окт-20, 07:42

Не, в обществе ты толкнёшь кого-то вниз, сам полетишь наверх, но всё общество целиком полетит вниз, вместе с тобой, хоть относительно общества ты и полетишь наверх.

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

43. "Релиз набора компиляторов LLVM 11.0 " –1 +/–

Сообщение от пох. (?), 13-Окт-20, 11:53

Но им-то - наплевать!
Самому взобраться на броневичок над остальными рабами гораздо прикольнее, чем быть пиццотым гребцом, не прикованным к скамье.

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

46. "Релиз набора компиляторов LLVM 11.0 " +/–

Сообщение от Аноним (46), 13-Окт-20, 12:22

хорошо ты Ленина мазанул, на корзину печенья и банку варенья заработал.

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

55. "Релиз набора компиляторов LLVM 11.0 " +/–

Сообщение от пох. (?), 13-Окт-20, 16:35

> хорошо ты Ленина мазанул, на корзину печенья и банку варенья заработал.
Но я броневик хочу! Печенье и варенье потом сам реквизирую, у недобитых плохишей.

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

79. "Релиз набора компиляторов LLVM 11.0 " +/–

Сообщение от Аноним (79), 16-Окт-20, 11:25

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

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

63. "Релиз набора компиляторов LLVM 11.0 " +/–

Сообщение от topin89 (ok), 13-Окт-20, 23:17

3. Необязательна (-mno-lvi-cfi -mno-lvi-hardening)

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

69. "Релиз набора компиляторов LLVM 11.0 " +1 +/–

Сообщение от Аноним (5), 14-Окт-20, 10:30

Есть нюанс - требует либо пересборки софта (очень долго и ресурсоёмко в случае Firefox или TensorFlow, даже pytorch и llvm часами пересобираются), либо как-то взять и занопить инструкцию в момент исполнения (напр. ядерным модулем).

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

9. "Релиз набора компиляторов LLVM 11.0 " +/–

Сообщение от Аноним (5), 12-Окт-20, 23:43

> Бэкенд для архитектуры AVR переведён из категории экспериментальных в стабильные, включённые в базовую поставку.
Зато PIC несколько лет назад выпилили. Теперь лифтинг делать некуда и натравливать retdec не на что.

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

11. "Релиз набора компиляторов LLVM 11.0 " +/–

Сообщение от Аноним (5), 12-Окт-20, 23:46

>"-fpch-codegen" и "-fpch-debuginfo" для генерации предкомпилированного заголовка (PCH) с отдельными объектными файлами для кода и debuginfo.
А толку? Их всё равно кроме Visual Studio ни одна система сборки не использует.

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

22. "Релиз набора компиляторов LLVM 11.0 " +1 +/–

Сообщение от Имя (?), 13-Окт-20, 02:48

Cmake, нет?

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

23. "Релиз набора компиляторов LLVM 11.0 " +/–

Сообщение от Аноним (23), 13-Окт-20, 05:18

И внезапно visual studio так же может использовать clang/llvm.

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

24. "Релиз набора компиляторов LLVM 11.0 " +/–

Сообщение от Имя (?), 13-Окт-20, 05:20

Не спорю, я и GCC прикручивал к студии, VS это только среда. А вы говорите про MS Build.

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

30. "Релиз набора компиляторов LLVM 11.0 " +/–

Сообщение от Аноним (5), 13-Окт-20, 07:45

Спасибо, значит уже добавили. Помню, как мне пришлось их из кода выпиливать, когда портировал на CMake + gcc.

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

54. "Релиз набора компиляторов LLVM 11.0 " –1 +/–

Сообщение от Ordu (ok), 13-Окт-20, 16:20

debug-info в отдельном файле -- это удобно. Можно хоть всю систему собрать с отладочной информацией, положив эту информацию отдельно куда-нибудь. Когда дело доходит до отладки чего-нибудь там, можно не парясь заглядывать в функции системно-установленных библиотек, и смотреть что там происходит. То есть, понятно, -O2 и прочие оптимизации делают отладку не столь гладкой, как хотелось бы, но в большинстве случаев этого достаточно, и не надо пересобирать glibc с отладочной инфой, и пересобирать полсистемы потом под эту версию glibc, только для того, чтобы посмотреть что там происходит.
И да, emerge так умеет. Я, правда, не уверен, что -fpch-debuginfo это как раз та штука, которая нужна для emerge -- я не знаю, как он это делает, не вникал. Может быть он использует binutils, чтобы из бинаря, полученного в результате линковки, вынуть отладочную инфу и положить в отдельный бинарь, а потом стрипает сам бинарь от всего лишнего.

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

60. "Релиз набора компиляторов LLVM 11.0 " +/–

Сообщение от Аноним (60), 13-Окт-20, 19:57

Это вообще не та штука. И objcopy для этой цели используется примерно во всех бинарных дистрибутивах.

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

14. "Релиз набора компиляторов LLVM 11.0 " –5 +/–

Сообщение от zzz (??), 13-Окт-20, 00:13

С таким прогрессом впору GCC именовать "LLVM-совместимым".

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

21. "Релиз набора компиляторов LLVM 11.0 " +/–

Сообщение от Андрей (??), 13-Окт-20, 01:33

> В бэкенд для архитектуры ARM добавлена поддержка процессоров Cortex-M55, Cortex-A77, Cortex-A78 и Cortex-X1.
С поддержкой Cortex-A77 как-то протормозили.

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

25. "Релиз набора компиляторов LLVM 11.0 " –5 +/–

Сообщение от Иваня (?), 13-Окт-20, 06:44

Ненужно. GCC по всем параметрам уделывает LLVM

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

31. "Релиз набора компиляторов LLVM 11.0 " +/–

Сообщение от Аноним (5), 13-Окт-20, 08:04

Возможно, что зависит от программы, архитектуры, для которой соберается, и от камня. На моём бенчмарке, который нифига не бенчмарк, а просто just for fun был сделан из обычной процедуры, для -march=k8 на AMD APU Carrizo clang порвал gcc на 287 миллисекунд. Для -march=native проигрыш на 289 миллисекунд. Для -march=cascadelake gcc порвал clang на 294 миллисекунд. Для остальных -march различия порядка 40-90 миллисекунд в пользу gcc.

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

32. "Релиз набора компиляторов LLVM 11.0 " +/–

Сообщение от Аноним (5), 13-Окт-20, 08:09

ошибка, для native дельта вообще 9 миллисекунд, но у native время больше, чем, например, у ivybridge

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

42. "Релиз набора компиляторов LLVM 11.0 " +1 +/–

Сообщение от Аноним (42), 13-Окт-20, 11:43

> clang порвал gcc на 287 миллисекунд.
кто-то кого-то порвал. Сам тест сколько миллисекунд длился?

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

45. "Релиз набора компиляторов LLVM 11.0 " –1 +/–

Сообщение от Аноним (45), 13-Окт-20, 12:19

100500

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

70. "Релиз набора компиляторов LLVM 11.0 " +/–

Сообщение от Аноним (5), 14-Окт-20, 10:36

https://github.com/KOLANICH/research_compiler_optimizations_...
Вот тут всё необходимое для воспроизведения исследования на вашем камне.

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

41. "Релиз набора компиляторов LLVM 11.0 " +/–

Сообщение от Аноним (41), 13-Окт-20, 11:37

>GCC по всем параметрам уделывает LLVM
Влажность мечт 146%

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

48. "Релиз набора компиляторов LLVM 11.0 " +1 +/–

Сообщение от erthink (ok), 13-Окт-20, 13:02

Исследовал тему, более чем, 9-й и тем более 10-й GCC именно что уделывает.
Пару лет назад я бы утверждал обратное, но ситуация постепенно принципиально поменялась.
В LLVM, на вскидку, накопилось более десятка багов типа https://bugs.llvm.org/show_bug.cgi?id=38217
И вот теперь либо палки, Г и гвозди, либо еще один раунд "немножко перепишем базовые внутренние интерфейсы" ;)

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

50. "Релиз набора компиляторов LLVM 11.0 " –2 +/–

Сообщение от Аноним (-), 13-Окт-20, 13:47

>Пару лет назад я бы утверждал обратное
И зря! Ты не знаешь как начинался проект LLVM. Изначально разработчики тупо скопировали исходники GCC и постепенно начали его переписывать. Так и создавалось LLVM.
Разработчиков GCC тоже когда-то задела популярность виртуальных машин. Они когда-то делали GCC виртуально-машинноподобным, но они отказались от этой затеи. И вернулись обратно в классическую модель: Язык_Программирования -------> ассемблер_AT&T --------> машинный код.
Если разработчики отказались от затеи виртуальных машин, значит был какой-то весомый МИНУС такого проектирования.

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

52. "Релиз набора компиляторов LLVM 11.0 " –1 +/–

Сообщение от Аноним (51), 13-Окт-20, 13:59

Минус что llvm уже существует и второй не нужен

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

53. "Релиз набора компиляторов LLVM 11.0 " +1 +/–

Сообщение от Аноним84701 (ok), 13-Окт-20, 14:24

> Разработчиков GCC тоже когда-то задела популярность виртуальных машин. Они когда-то делали
> GCC виртуально-машинноподобным, но они отказались от этой затеи. И вернулись обратно
> в классическую модель: Язык_Программирования -------> ассемблер_AT&T --------> машинный код.
А они о том, что "вернулись", знают? o_O

cat hello.c && gcc hello.c -fdump-final-insns
#include <stdio.h>
int main(void) {
    printf("hello %d", 1+4);
    return 0;
}
tail hello.o.gkd
(insn/f # 0 0 2 (set (reg/f:DI 6 bp)
        (mem:DI (post_inc:DI (reg/f:DI 7 sp)) [  S8 A8])) "hello.c":5:1# {*popdi1}
     (expr_list:REG_CFA_DEF_CFA (plus:DI (reg/f:DI 7 sp)
            (const_int 8 [0x8]))
        (nil)))
(jump_insn # 0 0 2 (simple_return) "hello.c":5:1# {simple_return_internal}
     (nil)
-> simple_return)
(barrier # 0 0)
(note # 0 0 NOTE_INSN_DELETED)

https://gcc.gnu.org/onlinedocs/gccint/RTL.html

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

57. "Релиз набора компиляторов LLVM 11.0 " +/–

Сообщение от n00by (ok), 13-Окт-20, 17:00

>[оверквотинг удален]
> sp)) [  S8 A8])) "hello.c":5:1# {*popdi1}
>      (expr_list:REG_CFA_DEF_CFA (plus:DI (reg/f:DI 7 sp)
>
> (const_int 8 [0x8]))
>         (nil)))
> (jump_insn # 0 0 2 (simple_return) "hello.c":5:1# {simple_return_internal}
>      (nil)
>  -> simple_return)
> (barrier # 0 0)
> (note # 0 0 NOTE_INSN_DELETED)
А что это? -fdump-final-insns выводит внутреннее представление, которое похоже на LISP.
bp, sp, di - регистры "архитектуры Интел", без привязки к режиму (разрядности).
Вот и с более привычном синтаксисе ассемблерного листинга они же:

$ gcc -masm=intel  -S hello.c -o -
#
main:
    .cfi_startproc
    push    rbp
    .cfi_def_cfa_offset 16
    .cfi_offset 6, -16
    mov    rbp, rsp
    .cfi_def_cfa_register 6
    mov    esi, 5
    lea    rdi, .LC0[rip]
    mov    eax, 0
    call    printf@PLT
    mov    eax, 0
    pop    rbp
    .cfi_def_cfa 7, 8
    ret

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

58. "Релиз набора компиляторов LLVM 11.0 " +/–

Сообщение от Аноним84701 (ok), 13-Окт-20, 18:42

> А что это? -fdump-final-insns выводит внутреннее представление, которое похоже на LISP.
> bp, sp, di - регистры "архитектуры Интел", без привязки к режиму (разрядности).
Дык, Register Transfer Language
> The last part of the compiler work is done on a low-level intermediate representation called Register Transfer Language. In this language, the instructions to be output are described, pretty much one by one, in an algebraic form that describes what the instruction does.
> RTL is inspired by Lisp lists. It has both an internal form,
(DI тут кстати == "Double Integer mode represents an eight-byte integer")
Трансформированный из промежуточного представления GIMPLE  (в который, ЕМНИП, трансформируют код фронтенды).
gcc -fdump-rtl-all даст тут более полную картинку.
https://gcc.gnu.org/onlinedocs/gccint/GIMPLE.html
> GIMPLE is a three-address representation derived from GENERIC by breaking down GENERIC expressions into tuples of no more than 3 operands (with some exceptions like function calls). GIMPLE was heavily influenced by the SIMPLE IL used by the McCAT compiler project at McGill University, though we have made some different choices.
В общем, никаких "AT&T" или тем более "сразу в ASM" ;)

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

66. "Релиз набора компиляторов LLVM 11.0 " +/–

Сообщение от n00by (ok), 14-Окт-20, 07:45

>> А что это? -fdump-final-insns выводит внутреннее представление, которое похоже на LISP.
>> bp, sp, di - регистры "архитектуры Интел", без привязки к режиму (разрядности).
> Дык, Register Transfer Language
>> The last part of the compiler work is done on a low-level intermediate representation called Register Transfer Language. In this language, the instructions to be output are described, pretty much one by one, in an algebraic form that describes what the instruction does.
>> RTL is inspired by Lisp lists. It has both an internal form,
То есть язык, описывающий машинные инструкции (целевой платформы?). В общем-то и так понятно, что для трансляции в машинный код мало смысла использовать мнемоники в виде текста, проще работать с деревом.
Имел ввиду, что для промежуточного представления может использоваться набор инструкций абстрактного процессора (например, стековый, где из регистров только аккумулятор -- что-то вроде Fort-машины). Вот это представление оптимизируется, а при генерации под целевую архитектуру верхушка стека заменяется реальными регистрами, в зависимости от их количества: st[0] -> eax, st[1] -> ebx и т.п.
>  (DI тут кстати == "Double Integer mode represents an eight-byte integer")
> Трансформированный из промежуточного представления GIMPLE  (в который, ЕМНИП, трансформируют
> код фронтенды).
> gcc -fdump-rtl-all даст тут более полную картинку.
> https://gcc.gnu.org/onlinedocs/gccint/GIMPLE.html
>> GIMPLE is a three-address representation derived from GENERIC by breaking down GENERIC expressions into tuples of no more than 3 operands (with some exceptions like function calls). GIMPLE was heavily influenced by the SIMPLE IL used by the McCAT compiler project at McGill University, though we have made some different choices.
Вот это уже больше похоже.
> В общем, никаких "AT&T" или тем более "сразу в ASM" ;)

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

64. "Релиз набора компиляторов LLVM 11.0 " +/–

Сообщение от Sem (??), 14-Окт-20, 01:38

> И зря! Ты не знаешь как начинался проект LLVM. Изначально разработчики тупо скопировали исходники GCC и постепенно начали его переписывать. Так и создавалось LLVM.
И зачем здесь демонстрировать свое невежество?

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

56. "Релиз набора компиляторов LLVM 11.0 " +/–

Сообщение от n00by (ok), 13-Окт-20, 16:44

Интересно, что оптимизаторы определяют семантику высокоуровнего кода, но есть разница в кодогенераторах:

$ cat popc.c
/** Определяет количество единичных бит. */
unsigned popc(unsigned d)
{
    // См. Генри Уоррен "Алгоритмические трюки для программистов"
    unsigned n = 0;
    while (d) {
        ++n;
        d &= d - 1;
    }
    return n;
}

$ gcc -masm=intel -march=native -O2 -S popc.c -o -
# Неинформативное вырезано
popc:
    popcnt  eax, edi ; ZF is set if SRC = 0, otherwise ZF is cleared.
    test    edi, edi
    mov     edx, 0   ; Зачем?
    cmove   eax, edx
    ret
#
    .ident    "GCC: (Gentoo 10.2.0-r2 p3) 10.2.0"

$ clang -masm=intel -march=native -O2 -S popc.c -o -
#
popc:                                   # @popc
    popcnt eax, edi
    ret
#
    .ident    "clang version 10.0.1 "

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

59. "Релиз набора компиляторов LLVM 11.0 " +2 +/–

Сообщение от Аноним84701 (ok), 13-Окт-20, 19:16

>  mov     edx, 0   ; Зачем?
Скорее всего (спекуляция), потому что на этапе промежуточного кода (gimple) оно выглядит так:
popc (unsigned int d)
{
  unsigned int D.1910;
  unsigned int n;
  n = 0;
  goto <D.1907>;
  <D.1906>:
  n = n + 1;
  _1 = d + 4294967295;
  d = d & _1;
  <D.1907>:
  if (d != 0) goto <D.1906>; else goto <D.1908>;
  <D.1908>:
  D.1910 = n;
  return D.1910;
}

На финальном этапе RTL

(insn:TI # 0 0 2 (parallel [
            (set (reg:SI 0 ax [orig:82 _2 ] [82])
                (popcount:SI (reg/v:SI 5 di [orig:84 d ] [84])))
            (clobber (reg:CC 17 flags))
...
(insn:TI # 0 0 2 (set (reg/v:SI 0 ax [orig:83 <retval> ] [83])
        (if_then_else:SI (ne (reg:CCZ 17 flags)
                (const_int 0 [0]))
            (reg:SI 0 ax [orig:82 _2 ] [82])
            (reg:SI 1 dx [86])))# {*movsicc_noc}
     (expr_list:REG_DEAD (reg:CCZ 17 flags)
        (expr_list:REG_DEAD (reg:SI 1 dx [86])
            (nil))))

Т.е. получилось "мухи" (while(d) - модифицируем n, потом возвращаем) отдельно, "котлеты" (control flow, если "не d", возвращаем 0) отдельно, т.е. семантика popcnt не учитывается до такой степени
(возможно, потому что на целевой платформе popcnt "как у интеля" может и не быть, возможно, потому что основная оптимизация делается на более высоком уровне).
clang -S -emit-llvm

define dso_local i32 @popc(i32 %0) local_unnamed_addr #0 {
  %2 = call i32 @llvm.ctpop.i32(i32 %0), !range !2
  ret i32 %2
}
The 'llvm.ctpop' family of intrinsics counts the number of bits set in a value.

Получается, высокоуровневый код транслируется в одну "виртуальную" инструкцию подсчета, которая на "конкретных" интелях реализуется простым popcnt.

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

67. "Релиз набора компиляторов LLVM 11.0 " +/–

Сообщение от n00by (ok), 14-Окт-20, 08:06

>>  mov     edx, 0   ; Зачем?
> Скорее всего (спекуляция)
    test    edi, edi
    mov     edx, 0
    cmove   eax, edx
Если о спекулятивном исполнении, то у cmove в любом случае зависимость по данным с test (ждёт флаг Z). А Z будет установлен, если edi ноль. Таким образом можно без лишнего регистра: cmove eax, edi
Тут либо как-то связано с переименованием регистра (register renaming, но талмуд я читал давно, а сейчас искать лень), либо ещё что (может и оптимизатор лажанул).
> Т.е. получилось "мухи" (while(d) - модифицируем n, потом возвращаем) отдельно, "котлеты"
> (control flow, если "не d", возвращаем 0) отдельно, т.е. семантика popcnt
> не учитывается до такой степени
> (возможно, потому что на целевой платформе popcnt "как у интеля" может и
> не быть, возможно, потому что основная оптимизация делается на более высоком
> уровне).
Если железо не поддерживает popcnt, выскочит #UD. Транслятор без подходящей -march генерирует цикл без  popcnt.
Вероятно, GCC решил соптимизировать исполнение тела цикла, когда на входе 0. Вот тогда спекулятивное исполнение вернёт результат через cmove, а медленная popcnt (у неё на ряде архитектур Latency=3 Throughput=1, тогда как у cmove Latency=1 Throughput=0.5) исполняться не будет.
В данном случае не всё так однозначно, код после GCC вроде больше, но иногда чуть быстрее.
>[оверквотинг удален]
>

> define dso_local i32 @popc(i32 %0) local_unnamed_addr #0 {
>   %2 = call i32 @llvm.ctpop.i32(i32 %0), !range !2
>   ret i32 %2
> }
> The 'llvm.ctpop' family of intrinsics counts the number of bits set in
> a value.
>

> Получается, высокоуровневый код транслируется в одну "виртуальную" инструкцию подсчета,
> которая на "конкретных" интелях реализуется простым popcnt.
Да, семантический анализатор понял, что именно делает код (интересно, как? может они всю книжку Уоррена туда запихали). На этой стадии трансляции GCC и Clang оказались на равных.

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

71. "Релиз набора компиляторов LLVM 11.0 " +2 +/–

Сообщение от Аноним84701 (ok), 14-Окт-20, 12:15

> Если о спекулятивном исполнении,
Да нет, это я так спекулирую (в смысле, с умным видом рассуждаю) ;)
> Да, семантический анализатор понял, что именно делает код (интересно, как? может они всю книжку Уоррена туда запихали).
Примерно да:
https://github.com/llvm-mirror/llvm/blob/master/lib/Transfor...

static bool detectPopcountIdiom(
...
// step 2: detect instructions corresponding to "x2 = x1 & (x1 - 1)"

Там еще интересный пассаж есть:

// TODO List:
//
// Future loop memory idioms to recognize:
//   memcmp, memmove, strlen, etc.
// Future floating point idioms to recognize in -ffast-math mode:
//   fpowi
// Future integer operation idioms to recognize:
//   ctpop
//
// Beware that isel's default lowering for ctpop is highly inefficient for
// i64 and larger types when i64 is legal and the value has few bits set.  It
// would be good to enhance isel to emit a loop for ctpop in this case.

А вот gcc я тыкал вчера минут 40 перед сном и так и не нашел, где "оно там" спрятанно.

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

73. "Релиз набора компиляторов LLVM 11.0 " +/–

Сообщение от erthink (ok), 14-Окт-20, 19:54

> mov     edx, 0   ; Зачем?
Так быстрее, хотя можно поспорить о том стоит ли игра свеч.
Насколько помню, вариант кода от GCC в 2 раза (или даже в 3) быстрее на нулях.
Т.е. если считать кол-во единичных бит в массиве, то "магия" добавленная gcc позволяет экономить по такту на каждом слове.
Кроме этого, при последующих вычислениях разница может быть еще более значительной (cmov может порождать два пути спекулятивного выполнения).
При этом, поведение актуального gcc 10.2 очень прецизионное. Добавляемая "магия" меняется в зависимости от целевого ядра (опция -march=), всего 4 варианта не считая цикла при отсутствии popcnt.
Ну и вишенка - gcc можно было-бы упрекнуть в генерации лишнего кода, но если задать -Os, то останется только popcnt.
Собственно, поэтому я говорю что сейчас gcc умеет больше чем llvm.

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

74. "Релиз набора компиляторов LLVM 11.0 " +/–

Сообщение от n00by (ok), 15-Окт-20, 11:04

>> mov     edx, 0   ; Зачем?
> Так быстрее, хотя можно поспорить о том стоит ли игра свеч.
> Насколько помню, вариант кода от GCC в 2 раза (или даже в
> 3) быстрее на нулях.
Про быстрее при 0 я писал https://www.opennet.me/openforum/vsluhforumID3/122094.html#67 (у popcnt на ряде архитектур Latency=3 Throughput=1, тогда как у cmove Latency=1 Throughput=0.5)
Вопрос именно в обнулении edx. cmove выполняется, если в edi ноль. То есть нужные данные и так есть. И зависимость cmove по данным (ZF) от test и так есть.
    test    edi, edi
    mov     edx, 0
    cmove   eax, edx
    test    edi, edi
    cmove   eax, edi
Т.е не ясно, почему 1й вариант, а не 2й.
> Т.е. если считать кол-во единичных бит в массиве, то "магия" добавленная gcc
> позволяет экономить по такту на каждом слове.
На массиве нулей. А если данные случайны? На каждом одном слове из 256, то есть 1/256 такта. При этом кеш инструкций расходуется непропорционально. Тут надо иметь ввиду, что у разработчиков премиальные процессоры с большим кешем, а в реальности у пользователя Целерон и многозадачная система, где крутится 68 онлайн-мессенджеров.
> Кроме этого, при последующих вычислениях разница может быть еще более значительной (cmov
> может порождать два пути спекулятивного выполнения).
> При этом, поведение актуального gcc 10.2 очень прецизионное. Добавляемая "магия" меняется
> в зависимости от целевого ядра (опция -march=), всего 4 варианта не
> считая цикла при отсутствии popcnt.
> Ну и вишенка - gcc можно было-бы упрекнуть в генерации лишнего кода,
> но если задать -Os, то останется только popcnt.
> Собственно, поэтому я говорю что сейчас gcc умеет больше чем llvm.
Дело может быть в области применения, а так же в том, что в Ваши задачи входит писать быстрый код, потому в конкретных и оптимизированных решениях GCC выигрывает, присваивая себе заслуги автора кода. А вот эта моя поделка https://www.opennet.me/opennews/art.shtml?num=53778 собранная GCC, выполняется в 2 раза медленнее (согласно и top, и perf). Написал как попало, принципиально не заморачиваясь оптимизацией (ну, только синус табличный), в цикле считаются float-ы, примерно так:

    if (!i) {
        vert->color = src;
    } else {
        vert->color.r = src.r * (1.0f + fsin(vert->pos.x + omega_bk + i));
        vert->color.g = src.g * (1.0f + fsin(vert->pos.y + omega_bk + i));
        vert->color.b = src.b * (1.0f + fsin(vert->pos.x + vert->pos.y + omega_bk + i));
        vert->color.a = src.a;
    }

Причину не искал, потому не могу пока говорить про данный случай предметно.
Просто пример, когда первый попавшийся чайник берёт Clang и выигрывает.

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

77. "Релиз набора компиляторов LLVM 11.0 " +/–

Сообщение от erthink (ok), 15-Окт-20, 23:28

> Т.е не ясно, почему 1й вариант, а не 2й.
Там четыре варианта в зависимости от целевого ядра.
Поиграйтесь флагом -march на https://godbolt.org/z/j9q4oG
> На массиве нулей. А если данные случайны? На каждом одном слове из
> 256, то есть 1/256 такта. При этом кеш инструкций расходуется непропорционально.
Тут "трусы vs крестик".
Если gcc опросили -Ofast он делает быстрее, если -Os то компактнее.
При необходимости более оптимального решения нужно использовать PGO, либо разметку функций атрибутами fast/cold (кстати, LLVM этого не умеет).
> Дело может быть в области применения, а так же в том, что
> в Ваши задачи входит писать быстрый код, потому в конкретных и
> оптимизированных решениях GCC выигрывает, присваивая себе заслуги автора кода. А вот
> эта моя поделка https://www.opennet.me/opennews/art.shtml?num=53778 собранная GCC,
> выполняется в 2 раза медленнее (согласно и top, и perf). Написал
> как попало, принципиально не заморачиваясь оптимизацией (ну, только синус табличный),
> в цикле считаются float-ы, примерно так:
[...]
> Причину не искал, потому не могу пока говорить про данный случай предметно.
Покажите ваш код (в минимально объеме) через https://godbolt.org/
Будет понятнее что там происходит.

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

81. "Релиз набора компиляторов LLVM 11.0 " +/–

Сообщение от n00by (ok), 16-Окт-20, 13:07

>> Т.е не ясно, почему 1й вариант, а не 2й.
> Там четыре варианта в зависимости от целевого ядра.
> Поиграйтесь флагом -march на https://godbolt.org/z/j9q4oG
Так варианты машинного кода не объясняют причину, почему выбрана именно такая. В моём случай "ясно", это когда я найду что-то вроде:
Assembly/Compiler Coding Rule 35. (M impact, ML generality) Use dependency-breaking-idiom
instructions to set a register to 0, or to break a false dependence chain resulting from re-use of
registers. In contexts where the condition codes must be preserved, move 0 into the register instead.
This requires more code space than using XOR and SUB, but avoids setting the condition codes.
>> На массиве нулей. А если данные случайны? На каждом одном слове из
>> 256, то есть 1/256 такта. При этом кеш инструкций расходуется непропорционально.
> Тут "трусы vs крестик".
> Если gcc опросили -Ofast он делает быстрее, если -Os то компактнее.
> При необходимости более оптимального решения нужно использовать PGO, либо разметку функций
> атрибутами fast/cold (кстати, LLVM этого не умеет).
Я, кстати, ошибся, 1 из 256 - это для байта. Для двойного слова выигрыш в среднем 1/0x10000000 тактов - т.е. на случайных данных отсутствует. С другой стороны, может авторы собирали какую-то статистику, когда эти биты подсчитывают (в моём случае - пиксели, а там 0 часто, то есть GCC угадал).
>[оверквотинг удален]
>> в Ваши задачи входит писать быстрый код, потому в конкретных и
>> оптимизированных решениях GCC выигрывает, присваивая себе заслуги автора кода. А вот
>> эта моя поделка https://www.opennet.me/opennews/art.shtml?num=53778 собранная GCC,
>> выполняется в 2 раза медленнее (согласно и top, и perf). Написал
>> как попало, принципиально не заморачиваясь оптимизацией (ну, только синус табличный),
>> в цикле считаются float-ы, примерно так:
> [...]
>> Причину не искал, потому не могу пока говорить про данный случай предметно.
> Покажите ваш код (в минимально объеме) через https://godbolt.org/
> Будет понятнее что там происходит.
Благодарю за предложение. Правда, не думаю, что кому-то следует заниматься моим кодом, когда я сам отложил вопрос в долгий ящик.)
Листинг той конкретной функции мало что даёт, в первом приближении причина видна из perf report:

    18.85%  foxhunt_clang   foxhunt_clang                  [.] poly_draw
    18.32%  foxhunt_clang   foxhunt_clang                  [.] colorer_title
    50.06%  foxhunt_gcc     foxhunt_gcc                    [.] colorer
     9.28%  foxhunt_gcc     foxhunt_gcc                    [.] poly_draw
Результат GCC напоминает Clang без LTO:

    43.26%  foxhunt_clang_n  foxhunt_clang_nolto            [.] colorer
    14.87%  foxhunt_clang_n  foxhunt_clang_nolto            [.] poly_draw
    12.63%  foxhunt_clang_n  foxhunt_clang_nolto            [.] colorer_title
Почему GCC не заинлайнил функцию из 5-ти строк, вызываемую из единственного места, загадка. Наверное, я плохо читал документацию по ключам командной строки. А ещё потому-что функция вызывается по указателю. То есть простое и очевидное для меня решение -- переписать с Си на плюсы, заменив указатели шаблоном и функторами, там не возникают проблемы со встраиванием тела функции (но оно подходит не очень, исполняемый файл после GCC и так большой, когда желательно уложиться в 64КБ).

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

82. "Релиз набора компиляторов LLVM 11.0 " +/–

Сообщение от erthink (ok), 16-Окт-20, 15:45

>>> Т.е не ясно, почему 1й вариант, а не 2й.
>> Там четыре варианта в зависимости от целевого ядра.
>> Поиграйтесь флагом -march на https://godbolt.org/z/j9q4oG
>
>Так варианты машинного кода не объясняют причину, почему выбрана именно такая. В моём случай "ясно", это когда я найду что-то вроде:
Ну как-бы очевидно что компилятор руководствуется подобными правилами, которые более-менее скрупулезно закодированные у него внутри.
С явным описанием таких правил у Штеуда достаточно плохо, по многим инструкциям нет даже базовой информации.
Если хотите поднатореть в этом больше чем позволяют официальные штеуд-мануалы и (например) рекомендации Agner Fog, то это болезненный и малополезный путь.
> Почему GCC не заинлайнил функцию из 5-ти строк, вызываемую из единственного места, загадка.
Чудес не бывает.
Вероятно, она объявлена не static и visibilty для DSO оставлен по-умолчанию, что заставляет GCC допускать возможность переопределения функции в другом DSO.
Либо еще какие-то проблемы с опциями оптимизации.

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

84. "Релиз набора компиляторов LLVM 11.0 " +/–

Сообщение от n00by (ok), 17-Окт-20, 17:55

>>>> Т.е не ясно, почему 1й вариант, а не 2й.
>>> Там четыре варианта в зависимости от целевого ядра.
>>> Поиграйтесь флагом -march на https://godbolt.org/z/j9q4oG
>>
>>Так варианты машинного кода не объясняют причину, почему выбрана именно такая. В моём случай "ясно", это когда я найду что-то вроде:
> Ну как-бы очевидно что компилятор руководствуется подобными правилами, которые более-менее
> скрупулезно закодированные у него внутри.
Так вопрос в том, насколько эти правила адекватны железу. Когда-то мне приходилось писать __asm nop, что бы MSVC не разворачивал цикл. Этот ноп давал +10% скорости.
> С явным описанием таких правил у Штеуда достаточно плохо, по многим инструкциям
> нет даже базовой информации.
А где разработчики GCC их взяли? Может они изучают код после Intel C Compiler, или получают эмпирически? Посмотрел бумажное издание Optimization Manual, там раздел "General Optimization" почти в сотню страниц, а в текущей версии на четверть сокращён (правда, и ядра другие), вероятно, в промежуточных изданиях что-то было, чего нет в этих. Есть надежда, что кое-что собрали по крупицам.
> Если хотите поднатореть в этом больше чем позволяют официальные штеуд-мануалы и (например)
> рекомендации Agner Fog, то это болезненный и малополезный путь.
Когда на горизонте маячит Эльбрус, не вижу смысла. Просто вышеприведённый код после GCC интуитивно вызвал недоверие, было интересно, можно ли найти рациональные объяснения тем лишним командам.
>> Почему GCC не заинлайнил функцию из 5-ти строк, вызываемую из единственного места, загадка.
> Чудес не бывает.
> Вероятно, она объявлена не static и visibilty для DSO оставлен по-умолчанию, что
> заставляет GCC допускать возможность переопределения функции в другом DSO.
static inline. Вообще, LTO оптимизирует на этапе связывания, насколько понимаю, может функцию в одном из мест вызова встроить, а другое её тело экспортировать.
> Либо еще какие-то проблемы с опциями оптимизации.
Наверное. Я же сразу предположил, что GCC выигрывает в руках специалистов по GCC.

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

85. "Релиз набора компиляторов LLVM 11.0 " +/–

Сообщение от n00by (ok), 18-Окт-20, 08:38

> Вероятно, она объявлена не static и visibilty для DSO оставлен по-умолчанию, что
> заставляет GCC допускать возможность переопределения функции в другом DSO.
Проверил гипотезу так:
объявил задействованные функции как static inline;
включил #include *.c с их определением в одну единицу трансляции, откуда происходит вызов;
добавил к -flto вот такое: -finline-limit=200000 --param inline-unit-growth=10000 -fwhole-program
Не инлайнит.
Clang инлайнит с -flto и без вышеуказанных манипуляций.

// сюда передаётся указатель на функцию, и отсюда осуществляется вызов.
/**
* \param painter       изменяет цвет вершин, либо NULL для раскрашивания в базовый цвет
*/
static inline
void poly_draw(const struct polygon *p, struct vec4 coordinate,
               fn_painter painter, struct color color, struct draw_ctx *restrict ctx);
// вот на что передаётся указатель
static inline __attribute__((always_inline))
void colorer(struct vertex *restrict vert, struct color src, unsigned i)
{
        if (!i) {
                vert->color = src;
        } else {
                vert->color.r = src.r * (1.0f + fsin(vert->pos.x + omega_bk + i));
                vert->color.g = src.g * (1.0f + fsin(vert->pos.y + omega_bk + i));
                vert->color.b = src.b * (1.0f + fsin(vert->pos.x + vert->pos.y + omega_bk + i));
                vert->color.a = src.a;
        }
}
// вызывавется так:
                        poly_draw(&square108, (struct vec4){ x, y, 0, dot_cnt },
                                  colorer, COLOR_BACKGROUND, ctx);

poly_draw() вызывается из нескольких мест мест с указателями на разные colorer-ы. Так что вроде-как есть причина, почему GCC считает, что инлайнить на надо. Но при этом Clang инлайнит единственный этот вызов poly_draw(), который по факту наиболее дорогой. В результате выигрывает по скорости вдвое. При этом с -O2 -flto размер исполняемого файла после strip у Clang 60720, у GCC - 69104 байт.
> Либо еще какие-то проблемы с опциями оптимизации.
Помимо вышеперечисленного добавил __attribute__((always_inline)) к poly_draw(). GCC заинлайнил (аналогично Clang-у -- только данный дорогой вызов). Стало быстрее на 20% по сравнению с прежним результатом GCC (60% от производительности Clang вместо прежних 50%), размер вырос до 77296. В общем, в данном случае для меня GCC не вариант.

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

87. "Релиз набора компиляторов LLVM 11.0 " +/–

Сообщение от Аноним (87), 21-Окт-20, 10:51

Как насчёт pgo? Все эти ручные твики на редкость не универсальны. А сам компилятор туп, как пробка. Поэтому ему нужны статы для эффективной оптимизации, шланг уделает. А lto в целом вещь довольно бесполезная (практически).

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

88. "Релиз набора компиляторов LLVM 11.0 " +/–

Сообщение от n00by (ok), 21-Окт-20, 12:44

> Как насчёт pgo? Все эти ручные твики на редкость не универсальны. А
> сам компилятор туп, как пробка. Поэтому ему нужны статы для эффективной
> оптимизации, шланг уделает.
В данном конкретном случае Clang (безо всяких твиков!) выполнил во время трансляции то что происходит при профилировке. Посчитал количество вызовов нескольких мелких функций (они все вызываются в циклах) и тело самой часто вызываемой подставил в место вызова.
> А lto в целом вещь довольно бесполезная (практически).
Её не от нечего делать прикрутили. Лет 15 назад на паре call+ret была сушественная просадка по скорости, потому инлайн мелких функций из другой единицы трансляции давал заметный выигрыш.

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

61. "Релиз набора компиляторов LLVM 11.0 " –3 +/–

Сообщение от Аноним (60), 13-Окт-20, 19:58

> GCC по всем параметрам уделывает LLVM
Вот когда по удобству кросс-компиляции уделает, тогда приходи со своим экспертным мнением.

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

78. "Релиз набора компиляторов LLVM 11.0 " +/–

Сообщение от erthink (ok), 15-Окт-20, 23:30

>> GCC по всем параметрам уделывает LLVM
> Вот когда по удобству кросс-компиляции уделает, тогда приходи со своим экспертным мнением.
Человек-снежинка?

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

83. "Релиз набора компиляторов LLVM 11.0 " –1 +/–

Сообщение от Аноним (83), 17-Окт-20, 17:49

n00by, erthink, Аноним84701 - втроём полнедели обсуждали обсуждали да таки ничего не поняли.
Тсс!!! только не говорите им, что ассемблер синтаксиса AT&T в GCC просто и гениально превращяется в машинный код.

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

86. "Релиз набора компиляторов LLVM 11.0 " +/–

Сообщение от n00by (ok), 18-Окт-20, 08:46

Ну да, я не понял, какое отношение имеет оптимизация графа вызовов (когда оптимизатор на основании количества вызовов решает, что вот этот вызов функции надо заинлайнить, а вон те - не надо) к целевому коду и его внутреннему представлению?

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

89. "Релиз набора компиляторов LLVM 11.0 " +/–

Сообщение от Andrey_Karpov (ok), 27-Окт-20, 15:03

Не мог пройти мимо и не потыкать палочкой :)
Проверка Clang 11 с помощью PVS-Studio - https://habr.com/ru/company/pvs-studio/blog/525248/

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

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Релиз набора компиляторов LLVM 11.0 "	+4 +/–
Сообщение от Аноним (1), 12-Окт-20, 22:53
Нужно, не копайте
Ответить \| Правка \| Наверх \| Cообщить модератору

3. "Релиз набора компиляторов LLVM 11.0 "	–8 +/–
Сообщение от Аноним (3), 12-Окт-20, 23:01
Для чего Fortran использовать можно, кроме вычислений? А то ощущение, что язык под одну нишу заточен.
Ответить \| Правка \| Наверх \| Cообщить модератору


	5. "Релиз набора компиляторов LLVM 11.0 "	–10 +/–
	Сообщение от Аноним (5), 12-Окт-20, 23:12
	А зачем нужен фортран, если есть C, C++, OpenCL, SyCL, а если и их мало, то Boost::Compute (по сути просто обёртка вокруг OpenCL для человечной инициализации), ArrayFire, а если и этого мало, то pyTorch, TensorFlow, MxNet, и даже недавний релиз NeoML от ABBYY, с зависимостями от проприетарной платной bloatare, дискриминирующей против AMD, Intel Performance Primitives.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	6. "Релиз набора компиляторов LLVM 11.0 "	+3 +/–
	Сообщение от Аноним (3), 12-Окт-20, 23:26
	Зачем библиотеки перечислять?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	7. "Релиз набора компиляторов LLVM 11.0 "	+3 +/–
	Сообщение от Аноним (5), 12-Окт-20, 23:31
	Потому что без них BLAS (оптимизированные операции линейной алгебры, вроде скалярного произведения и разложений, причём каждой операции по несколько видов, в зависимости от симметрии матрицы) из коробки нет. Ещё AMD OpenCL BLAS и FFT забыл перечислить.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	36. "Релиз набора компиляторов LLVM 11.0 "	+7 +/–
	Сообщение от YetAnotherOnanym (ok), 13-Окт-20, 09:45
	Чтобы показать, что он про них читал.
	Ответить \| Правка \| К родителю #6 \| Наверх \| Cообщить модератору


	62. "Релиз набора компиляторов LLVM 11.0 "	–1 +/–
	Сообщение от Gefest (?), 13-Окт-20, 20:21
	Патамушта это все не для людей,это все для погроммистов, чюдо ты наше.
	Ответить \| Правка \| К родителю #5 \| Наверх \| Cообщить модератору


	10. "Релиз набора компиляторов LLVM 11.0 "	+4 +/–
	Сообщение от Я (??), 12-Окт-20, 23:44
	Fortran вечен!!!
	Ответить \| Правка \| К родителю #3 \| Наверх \| Cообщить модератору


	12. "Релиз набора компиляторов LLVM 11.0 "	–3 +/–
	Сообщение от Аноним (3), 12-Окт-20, 23:54
	Можно на нём операционную систему написать или микроконтроллеры прогать?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	15. "Релиз набора компиляторов LLVM 11.0 "	+6 +/–
	Сообщение от Аноним (15), 13-Окт-20, 00:16
	Я под ВЭБ на нем прогаю, вместо жаваскрипта. Олдскульненько так.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	33. "Релиз набора компиляторов LLVM 11.0 "	+4 +/–
	Сообщение от ksjdjfgklsjdklgfj (?), 13-Окт-20, 08:29
	блин, я аж пивом подавился когда распарсил :)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	39. "Релиз набора компиляторов LLVM 11.0 "	–1 +/–
	Сообщение от ИмяХ (?), 13-Окт-20, 11:22
	Можно ли молотком хлеб порезать или полы подмести?
	Ответить \| Правка \| К родителю #12 \| Наверх \| Cообщить модератору


	47. "Релиз набора компиляторов LLVM 11.0 "	+1 +/–
	Сообщение от Аноним (3), 13-Окт-20, 12:25
	Некорректное сравнение.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	80. "Релиз набора компиляторов LLVM 11.0 "	+/–
	Сообщение от Аноним (80), 16-Окт-20, 11:45
	Заморозь в форме ножа, желательно хлебного (как пила чтобы лезвие было); Мойка высокого давления и направленной струёй вжух, вжух
	Ответить \| Правка \| К родителю #39 \| Наверх \| Cообщить модератору


	18. "Релиз набора компиляторов LLVM 11.0 "	–3 +/–
	Сообщение от Аноним (18), 13-Окт-20, 00:48
	>Для чего Fortran использовать можно, кроме вычислений? Для повышения чсв разве что.
	Ответить \| Правка \| К родителю #3 \| Наверх \| Cообщить модератору


	19. "Релиз набора компиляторов LLVM 11.0 "	–13 +/–
	Сообщение от Аноним (19), 13-Окт-20, 01:05
	Ни для чего. В llvm он нужен только для поддежрки кое-какого распространнного легаси на этом г-не написанного, чтобы исключить необходимость в gfortran, который тащит gcc и прочий несовместимый мусор.
	Ответить \| Правка \| К родителю #3 \| Наверх \| Cообщить модератору


	65. "Релиз набора компиляторов LLVM 11.0 "	+5 +/–
	Сообщение от Аноним (65), 14-Окт-20, 02:01
	Уровень опеннетовских анонимных экспертов порой просто поражает.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	26. "Релиз набора компиляторов LLVM 11.0 "	+5 +/–
	Сообщение от yep (?), 13-Окт-20, 07:06
	Да, он изначально заточен и его продолжают затачивать прежде всего под цели вычислений.
	Ответить \| Правка \| К родителю #3 \| Наверх \| Cообщить модератору


	37. "Релиз набора компиляторов LLVM 11.0 "	+/–
	Сообщение от nobody (??), 13-Окт-20, 11:02
	Это язык для физиков и математиков, а не для программистов. Нахрен им его ещё для чего-то использовать?
	Ответить \| Правка \| К родителю #3 \| Наверх \| Cообщить модератору


	38. "Релиз набора компиляторов LLVM 11.0 "	–2 +/–
	Сообщение от Sw00p aka Jerom (?), 13-Окт-20, 11:14
	а вам все готовое подавай? пс: не подскажите каким языком пользуются "макаки"?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	44. "Релиз набора компиляторов LLVM 11.0 "	+3 +/–
	Сообщение от Zlo (??), 13-Окт-20, 11:53
	AppleScript
	Ответить \| Правка \| Наверх \| Cообщить модератору


	72. "Релиз набора компиляторов LLVM 11.0 "	+/–
	Сообщение от fsb4000 (?), 14-Окт-20, 17:10
	А как же Haskell? Разве не Haskell язык для математиков?
	Ответить \| Правка \| К родителю #37 \| Наверх \| Cообщить модератору


	51. "Релиз набора компиляторов LLVM 11.0 "	+/–
	Сообщение от Аноним (51), 13-Окт-20, 13:51
	Фортран это почти ассемблер с человеческим лицом. Что-то сложное типа БД на нем делать боль.
	Ответить \| Правка \| К родителю #3 \| Наверх \| Cообщить модератору

4. "Релиз набора компиляторов LLVM 11.0 "	+/–
Сообщение от Аноним (5), 12-Окт-20, 23:05
А грёбанный долгоиграющий баг с неправильными флагами компоновки при использовании стандартной библиотеки glibc при включённом positional-independent code при использовании clang в качестве фронтенда линкера так и не пофиксили. Приходится изращаться для обхода.
Ответить \| Правка \| Наверх \| Cообщить модератору


	40. "Релиз набора компиляторов LLVM 11.0 "	+/–
	Сообщение от Аноним (40), 13-Окт-20, 11:36
	А можно чуть поподробнее, пожалуйста? Интересно.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	68. "Релиз набора компиляторов LLVM 11.0 "	+/–
	Сообщение от Аноним (5), 14-Окт-20, 10:25
	Можно. https://github.com/pocl/pocl/blob/master/cmake/clangLinkerWo... https://bugs.llvm.org/show_bug.cgi?id=44594
	Ответить \| Правка \| Наверх \| Cообщить модератору


	49. "Релиз набора компиляторов LLVM 11.0 "	–2 +/–
	Сообщение от Аноним (-), 13-Окт-20, 13:39
	Юзай GCC!
	Ответить \| Правка \| К родителю #4 \| Наверх \| Cообщить модератору

8. "Релиз набора компиляторов LLVM 11.0 "	+2 +/–
Сообщение от Аноним (5), 12-Окт-20, 23:41
>Добавлена защита от атак LVI (Load Value Injection) 1. Большая деградация производительности. 2. Требует SSE2.
Ответить \| Правка \| Наверх \| Cообщить модератору


	13. "Релиз набора компиляторов LLVM 11.0 "	+5 +/–
	Сообщение от Аноним (13), 13-Окт-20, 00:02
	>Требует SSE2 Который есть во всех х64 процессорах. Что сказать-то хотел?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	16. "Релиз набора компиляторов LLVM 11.0 "	+4 +/–
	Сообщение от Аноним (5), 13-Окт-20, 00:30
	>Который есть во всех х64 процессорах В aarch64 этого набора инструкций нет ;) А сказать я хотел, что есть люди (которые даже софт не собирают, только на форумах - ****ят), которым очень не терпится прибить 32-бита, а вернее не столько прибить 32-бита, сколько нагадить его пользователям, при этом прикрывшись другими мотивами. Если кого-то толкнуть вниз, сам полетишь вверх - им кажется. Не понимают, что в обществе закон сохранения импульса не работает.
	Ответить \| Правка \| Наверх \| Cообщить модератору