[plug] [обсуждение плана]

[Eugene Sharygin]

Вячеслав Козырев <weautify at gmail.com> writes:

> То есть мы запускаем qbe примерно так:
> ./qbe [input-file] [options] [-plugs path1.so path2.so .. pathn.so]
>
> Анализирующие проходы нас интересуют мало, если они не используются, в
> конечном счёте, в оптимизациях (правильно?),

Можно так считать, да. Если результат анализа нужно будет в каком-то
формате представить в потоке вывода, то можно будет реализовать
соответствующий no-op оптимизационный проход (printer).

> а значит есть смысл указывать, анализирующий проход реализован в
> плагине или оптимизационный. Из всей этой кучи плагинов мы выбираем
> только те, которые, в конечном счёте, являются оптимизациями. Причём,
> вообще говоря, не все оптимизации могут быть независимыми, поэтому в
> конечном счёте может выстроиться иерархия оптимизационных проходов.

В общем случае зависимости между плагинами будут, и должен быть какой-то
интерфейс, через который оптимизация или анализ может получить
результаты другого анализа.

Если составлять пайплайн заранее на основе проходов, которые нужно
запустить, то нужно будет знать по крайней мере (1) какие анализы перед
проходом нужно будет иметь готовыми и (2) какие анализы проход
инвалидирует (для начала можно считать, что инвалидируются все анализы
при каждой оптимизации). Для этого потребуются соответствующие функции,
которые из плагина QBE будет дёргать.

Можно пайплайн не составлять, а вычислять все анализы лениво, при первом
обращении к функции получения результата анализа, если результат анализа
ещё не известен.

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

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

> Если происходит оптимизация, то приходится пересчитывать предыдущие
> анализы. А значит, желательно не учитывать порядок включения плагинов
> в командной строке, а запускать их согласно некоторым указаниям в
> самом плагине.

Пользователь может хотеть выполнить серию вообще говоря независимых
проходов в определённом порядке (например, вначале удаление бесполезного
кода, потом удаление недостижимого). Было бы хорошо, если бы этот
вариант использования тоже поддерживался.

> При этом сначала запускать оптимизационные плагины, а потом
> анализирующие (чтобы анализ соответствовал измененному в процессе
> оптимизации IR).
>
> (Или лучше считать, что оптимизационный проход указан ровно один?)

Думаю, что лучше поддержать несколько проходов. См. предыдущий комментарий.

> 18 марта 2018 г., 18:55 пользователь Eugene Sharygin <eush at ispras.ru> написал:
>> Привет,
>>
>> Vladislav Ivanishin <vlad at ispras.ru> writes:
>>
>>> Добрый день,
>>>
>>> Вячеслав Козырев <weautify at gmail.com> writes:
>>>
>>>> Начну, пожалуй.
>>>>
>>>> Первое, что стоит сказать, есть проблема, связанная с тем, что без
>>>> механизма подключения плагинов работа над собственно плагинами
>>>> несколько осложняется. Однако больше двух человек работать над ним,
>>>> пожалуй, не смогут - это будет перебор.
>>>> Поэтому предлагается взять двум человечкам работы над механизмом
>>>> подключения плагинов, а двум другим тем временем отдельно заниматься
>>>> плагинами с поправкой на то, чтобы плагины работали сами по себе (как
>>>> в работе по курсу "конструирование компиляторов"). Затем, когда работа
>>>> над механизмом подключения плагинов будет закончена, можно начинать
>>>> нормально оформлять плагины и делать новые уже сразу плагинами.
>>>> Вопрос, как распределить работу на этом этапе практикума, остаётся
>>>> открытым.
>>>>
>>>> Мне хочется заниматься подключением плагинов поначалу, и считаю, что
>>>> на это можно отвести две недели - их должно быть более чем достаточно.
>>>> После этого все будут заниматься сборкой плагинов. Вопрос, какие
>>>> плагины реализовать, остаётся открытым.
>>>
>>> В принципе, реализация чего-либо как плагина должна быть
>>> простой. Т.е. нужно просто взять имеющийся проход (из домашнего задания)
>>> и воспользоваться интерфейсом, который нужно создать.
>>>
>>> Обычно соглашения для плагинов выглядят примерно так. Плагин собирается
>>> как динамическая библиотека, и в нём обязательно определена функция (или
>>> несколько) с известным именем, например, `onload'. А qbe должен
>>> научиться в командной строке распознавать что-нибудь вроде
>>> -plug=path-to-plugin.so (может быть и что-то более сложное, к примеру,
>>> плагин может принимать параметры, тогда они должны задаваться там же --
>>> интерфейс вам надо продумать). Соответственно, если в командной строке
>>> такое встретилось, то в какой-то момент qbe должен вызвать
>>> dlopen(path_to_plugin,...), затем dlsym(..., "onload") и вызвать
>>> полученную функцию по указателю. Функция же onload в плагине может
>>> использовать интерфейсы из all.h. Как-то так всё срастается.
>>>
>>> На самом деле, это упрощённое описание интерфейса. К примеру, вы хотите
>>> иметь какой-то оптимизационный проход в виде плагина. Если все действия
>>> производить в `onload', получится, что qbe должен знать, в какой именно
>>> момент вызывать onload (при том, что он не должен знать наперёд, какие
>>> плагины будут написаны). Поэтому нужна какая-то система хуков. Например,
>>> onload будет вызываться достаточно рано и куда-то записывать callback'и,
>>> которые qbe вызовет, когда придёт время. А время придёт, когда наступит
>>> какое-то событие (например, завершится проход с определённым именем,
>>> которое задаёт плагин). Таким образом, в вашу задачу входит определение
>>> набора событий, где будут расставлены хуки, и патчинг qbe
>>> соответствующим образом.
>>>
>>> В qbe (когда он используется не как библиотека, а как компилятор)
>>> выполняется ряд проходов (см. main.c). Возможно, есть смысл переписать
>>> их вызовы в новой концепции, т.е. определить единый интерфейс для всех
>>> этих проходов и добавить менеджер проходов.
>>
>> Было бы хорошо иметь не только интерфейс, позволяющий встраиваться в
>> основной пайплайн QBE (IR -> Asm), но и возможность запустить цепочку
>> проходов в отдельности (IR -> IR). Пожалуй, для целей курса это было бы
>> даже полезнее.
>>
>> --
>> Regards,
>> Eugene Sharygin,
>> ISP RAS.

--
Regards,
Eugene Sharygin,
ISP RAS.