The OpenNET Project / Index page

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

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


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

Оглавление

Релиз набора компиляторов LLVM 13.0, opennews (??), 05-Окт-21, (0) [смотреть все]

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


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

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

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

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

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

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

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

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

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

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

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

50. "Релиз набора компиляторов LLVM 13.0"  –1 +/–
Сообщение от Урри (ok), 05-Окт-21, 21:57 
> Атрибут musttail, что в gcc, что в llvm, делает tail-call оптимизацию обязательной.

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

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

    return q * r;
}

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

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

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

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

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

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

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

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

/0

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

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

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

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


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

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

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

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

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

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

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

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

47. "Релиз набора компиляторов LLVM 13.0"  –1 +/–
Сообщение от анонн (ok), 05-Окт-21, 20:46 
>> _гарантированных_ хвостовых вызовов
>> If a return statement is marked musttail, this indicates that the compiler must generate a tail call for the program to be correct, even when optimizations are disabled.
> gcc это (tail-call optimization) вроде как уже 20 лет умеет, без всяких там __attribute__.

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

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

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

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

49. "Релиз набора компиляторов LLVM 13.0"  –3 +/–
Сообщение от Урри (ok), 05-Окт-21, 21:55 
> чем отличается _возможная_ tail call оптимизация от _гарантированной_?

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

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

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

    return q * r;
}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

60. "Релиз набора компиляторов LLVM 13.0"  +/–
Сообщение от анонн (ok), 05-Окт-21, 23:37 
> Урри сел в лужу с "gcc это (tail-call optimization) вроде как уже 20 лет умеет"
> Урри сел в лужу с хвостовой рекурсией
> Урри важно надул щечки и сделал вид принимающего грязевую ванну
> Слив, как говорится, засчитан.

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

73. "Релиз набора компиляторов LLVM 13.0"  +/–
Сообщение от n00by (ok), 06-Окт-21, 07:50 
> Ссылка: https://blog.reverberate.org/2021/04/21/musttail-efficient-i...
> Большой разбор и в конце цитата:
> ---
> One of the biggest caveats with this approach is that these beautiful
> assembly sequences get catastrophically pessimized if any non tail calls are
> present. Any non tail call forces a stack frame to be
> created, and a lot of data spills to the stack.
> ---

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


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

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

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

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

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

87. "Релиз набора компиляторов LLVM 13.0"  +/–
Сообщение от n00by (ok), 07-Окт-21, 07:35 
По поводу push rax смотрим AMD64 ABI Draft 1.0

3.2.2 The Stack Frame

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

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

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


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

3.4.2.6 Optimization for Decoded ICache

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

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

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

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

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

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

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

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




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

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