bmstu-iu9 / bmstu-iu9/refal-5-lambda
Удалять и не порождать неиспользуемые функции
- Dominant language
- C++
- Stars
- 97
- Forks
- 40
- PR merge metrics
- No merged PRs in 30d
Description
**UPD:** более верная постановка задачи в комментариях (https://github.com/bmstu-iu9/refal-5-lambda/issues/228#issuecomment-714307025).
Эта задача — подзадача для #91.
@InfiniteDisorder реализовал оптимизацию встраивания и прогонки #122, однако, реализовал не оптимально. Когда в процессе прогонки в программе формируется вызов «усечённой» функции ``, тело функции `Func*n` добавляется к синтаксическому дереву. Добавление это преждевременное, поскольку на следующей итерации оптимизации вызов `Func*n` может прогнаться/встроиться и в конечной программе `Func*n` никогда вызываться не будет.
Правильным является вариант, когда функции `Func*n` добавляются в дерево только тогда, когда вызов `` становится холодным, т.е. не подлежащим дальнейшей оптимизации. Но что, если лимит итераций иссяк, но функцию `Func*n` можно ещё прогнать? В этом случае усечённая `Func*n` должна добавляться в `OptTree-Drive-Finalize`.
Вообще, привлекательно выглядит вариант вообще не добавлять в дерево тела встраиваемых или прогоняемых функций, если они не вызываются из единицы трансляции или не entry. Но так делать нельзя, поскольку такие функции могут вызываться через `Mu`, т.е. должны быть доступны для рефлексии. Функции `Func*n` или `Func@n` могут пристутствовать в программе или не присутствовать, в зависимости от ключей компиляции, но функция `Func` без суффиксов присутствовать должна обязательно. В принципе, можно не добавлять в дерево вспомогательные функции вроде `Func\n`, `Func=n`, `Func:n` и другие (например, `Func?m?n`, добавляемые `Desugaring-UnCondition`), если они растворились при оптимизации. Надо оценить затратность реализации и, возможно, так и сделать.
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.