[ssa] [я столкнулся с проблемами]
Spiridonov Alexander
spiridoncha at gmail.com
Wed Apr 18 04:53:51 MSK 2018
On Mon, Apr 16, 2018 at 07:55:55PM +0300, Vladislav Ivanishin wrote:
> On April 16, 2018 7:24:26 PM GMT+03:00, Spiridonov Alexander <spiridoncha at gmail.com> wrote:
> >On Mon, Apr 16, 2018 at 03:09:08PM +0300, Vladislav Ivanishin wrote:
> >> Spiridonov Alexander <spiridoncha at gmail.com> writes:
> >>
> >> > On Mon, Apr 16, 2018 at 12:50:01PM +0300, Vladislav Ivanishin
> >wrote:
> >> >> Добрый день, Александр,
> >> >>
> >> >> Spiridonov Alexander <spiridoncha at gmail.com> writes:
> >> >>
> >> >> > Короче мне дико не нравится идея править qbe,
> >> >> > она предназначена чтоб создавать из IR исполняемые файлы,
> >> >> > а не работать на уровне source2source, мне кажется что мы просто
> >> >> > зароемся если захотим дополнить таким функционалом qbe.
> >> >> >
> >> >> > Если конкретнее(это только на первый взгляд):
> >> >> > * Нужно выводить не только функцию, но и типы используемые в
> >ней
> >> >> > https://c9x.me/compile/doc/il.html#Aggregate-Types (я не
> >> >> > нашёл ничего готового в qbe для этого)
> >> >> > * Нужно выводить не только функцию, но и определяемые данные
> >> >> > https://c9x.me/compile/doc/il.html#Data (я не
> >> >> > нашёл ничего готового в qbe для этого)
> >> >> > * Нужно переписать часть отвечающую за вывод call
> >> >> > https://c9x.me/compile/doc/il.html#Call
> >> >> > * Ну и по-мелочи ещё всякие retw и т.п.
> >> >>
> >> >> Для задачи в ejudge вполне достаточно выводить только функцию.
> >Задача
> >> >> ведь состоит в том, чтобы перевести её представление в SSA форму.
> >Это
> >> >> преобразование никак не затрагивает типы, определённые в
> >программе.
> >> >>
> >> >> Конечно, программа без типов и данных становится непригодной для
> >> >> генирации по ней машинного кода, но это не должно понадобиться. В
> >> >> частности, ssa.cpp в репозитории сравнивает внутренние
> >представления
> >> >> программ.
> >> >>
> >> >> Или без типов возникает ошибка парсинга?
> >> > Да, выглядит это так:
> >> > <original>:1: undefined type :mem
> >> > Пример для воспроизведения:
> >> > export function :mem $test() {
> >> > @ini
> >> > %p =l alloc4 17
> >> > ret %p # здесь было после printfn так - retc %p, :mem
> >> > }
> >>
> >> Тогда самое простое решение -- не писать в тестах агрегатных типов.
> >>
> >
> >А студенту решающему эту задачу это всё-равно не поможет,
> >он спокойно может получить представление с агрегатными типами.
> >Я вот когда какие-то задачки делал, генерил IR каким-то компилятором
> >для тестов, там точно были типы.
>
> Можно в условии указать, что их не будет. Тогда если студент возьмётся их обрабатывать, ... он молодец. А авторам авторкского решения не придётся об этом думать.
>
> >> >> > В таком виде при решении задачи нужно будет по сути только
> >определить
> >> >> > куда нужно вставлять фи-функции для преобразования в усечённую
> >> >> > ssa.
> >> >> >
> >> >> > Хотелось бы услышать кто что думает по этому поводу.
> >> >>
> >> >> У меня нет больших возражений, но вывод полной программы для меня
> >> >> предпочтителен.
> >> >>
> >> >> В принципе, такой содержит всю необходимую информацию -- в
> >совокупностью
> >> >> со входными данными. В этом и состоит неудобство: для тестирования
> >можно
> >> >> было бы выводить целую программу в виде графа (генерировать
> >> >> представление graphviz и запускать dot) и взглядом определять,
> >корректра
> >> >> ли ssa-форма. В предложенном Вами подходе нужно будет выводить
> >отдельно
> >> >> исходную программу и соотносить с полученным ответом.
> >> > Ну с новым форматом я полагал делать это так:
> >> > * копипастим и припиливаем вывод под наш формат для построения ssa
> >из qbe
> >> > * считаем это эталонным решением
> >> > * генерим с помощью него тесты
> >> > Ну а само тестирование просто проверяет что вывод пришедшего
> >решения
> >> > совпадает с тем что мы нагенерили(ну, с поправкой на возможное
> >> > несовпадение порядка)
> >>
> >> Это понятно. Я имел в виду тестирование с точки зрения студентов,
> >> которые будут впоследствии решать эту задачу. Им будет удобнее
> >смотреть
> >> на ГПУ в SSA целиком, чем на фи-функции и ГПУ по отдельности.
> >>
> >Я согласен что это удобнее, но с таким же успехом для этих целей можно
> >отладочные вызовы printfn вставлять, в этом её и смысл видимо.
>
> Это если на деле изменять само представление, а не хранить фи-функции где-то сбоку.
>
> >Я Вашу позицию понял, надеюсь парни сегодня-завтра прочитают наш диалог
> >и отпишутся что думают по этому поводу, а там уже и решим что делать.
>
> В общем, да, спасибо; как я говорил, оба варианта в целом ок.
>
> Формально сегодня день заключительного отчета, советую парням поторопиться.
Я сегодня положил в репозиторий тот вариант, который предлагал, нужно
чего-либо ждать или можно сразу отчёт писать?
>
> >> --
> >> Влад
> >
> >--
> >С уважением,
> >Спиридонов Александр.
> >_______________________________________________
> >ssa mailing list
> >ssa at compilers.ispras.ru
> >https://compilers.ispras.ru/cgi-bin/mailman/listinfo/ssa
>
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
> Vlad
--
С уважением,
Спиридонов Александр.
More information about the ssa
mailing list