[ssa] [я столкнулся с проблемами]

[Spiridonov Alexander]

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 вставлять, в этом её и смысл видимо.

Я Вашу позицию понял, надеюсь парни сегодня-завтра прочитают наш диалог
и отпишутся что думают по этому поводу, а там уже и решим что делать.
> -- 
> Влад

-- 
С уважением,
Спиридонов Александр.