Примерно похожая вещь в clang-tidy. Там просят показать, какие проекты срабатывают на новой проверке

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

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

но если паттерн реализует сторонний контрибьютер - то можно принять в принципе

Так если пр уже есть, то что?))

ну оптимизации - это
+ к размеру компилятора (мы его с собой таскаем в самом популярном сценарии)
+ к времени компиляции
+ к размеру кода (к сожалению, у нас пока нет DSL, но возможно появится, хотя в ЛЛВМ тоже его нет и всё в коде) == минус к читабельности, осложняет рефакторинг.
+ потенциальные баги (любой новый необязательный код - потенциальный исчточник багов)
+ трата времени на кодревью

и всё это за сомнительный бенефит в случае оптимизаий без срабатываний джит-диффа

Привет, тут есть кто может в Raku?

С одной стороны это правильно сосредоточиваться сначала на sophisticated оптимизациях а потом уже допиливать пипхол. Но оногда на одном пипхоле можно очень многое сделать, например у нас нету трансформаций пока для стандарной библиотеки и когда напишешь например Mathf.cos(Mathf.PI) оно будет честно компилировать и оптимизировать весь код и только за счет пипхола соптимизирует это все до одной константы «-1». Да это затратно, но зато работает всегда уже сейчас, а потом уже можно будет и что нибудь вроде StdLibSimplifierPass сделать как в LLVM =)

Но у нас AOT. Можем себе позволить. С JIT история совсем другая была бы конечно

Ну кстати фолдинг констант для math ф-ций небесполезно да 😊

НУ это как минимум 3 трансформации - constant folding + inlining + DAE (dead argument ellimination)

на геймдвиглах, физических движках были срабатывания

Кстати кроме DAE еще неплохо и DRE делать, то есть  дропать мертвый код с конца функции если она что то возвращает, но при вызове никто этот результат не использует во время фактического вызова

Что бы потом на собеседовании можно было задавать вопросы про undefined behavior:
Как отработает этот код?

{
if ( a == NULL ) return;
f(a[0]);
...
}

Вообще в идеале ни одна оптимизация никак не должна влиять на поведение программы. За этим тщательно следят, используют fuzzing тестирование, формальные/автоматические верификации через alive2 и т д

Конечно это не касается таких небезопасных наборов как ffast-math к примеру

Вопрос по оптимизации плавающей точки - какие преобразования вообще там не меняют результат, а только увеличивают скорость?

Они вообще есть, кроме убирания тривиальных * 0.0 и аналогичного?

См сюда:
https://herbie.uwplse.org/

Или сюда:
http://cseweb.ucsd.edu/~alexss/2017/04/22/introducing-herbgrind.html

Спасибо, занятная штука.

> не меняют результат
> увеличивают точность

🤣🤣🤣🤣

Всё таки, это линтер.