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

[Вячеслав Козырев]

То есть мы запускаем qbe примерно так:
./qbe [input-file] [options] [-plugs path1.so path2.so .. pathn.so]

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

Если происходит оптимизация, то приходится пересчитывать предыдущие
анализы. А значит, желательно не учитывать порядок включения плагинов
в командной строке, а запускать их согласно некоторым указаниям в
самом плагине. При этом сначала запускать оптимизационные плагины, а
потом анализирующие (чтобы анализ соответствовал измененному в
процессе оптимизации 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.