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

[Vladislav Ivanishin]

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
>   }

Тогда самое простое решение -- не писать в тестах агрегатных типов.

>> > В таком виде при решении задачи нужно будет по сути только определить
>> > куда нужно вставлять фи-функции для преобразования в усечённую
>> > ssa.
>> >
>> > Хотелось бы услышать кто что думает по этому поводу.
>> 
>> У меня нет больших возражений, но вывод полной программы для меня
>> предпочтителен.
>> 
>> В принципе, такой содержит всю необходимую информацию -- в совокупностью
>> со входными данными. В этом и состоит неудобство: для тестирования можно
>> было бы выводить целую программу в виде графа (генерировать
>> представление graphviz и запускать dot) и взглядом определять, корректра
>> ли ssa-форма. В предложенном Вами подходе нужно будет выводить отдельно
>> исходную программу и соотносить с полученным ответом.
> Ну с новым форматом я полагал делать это так:
>  * копипастим и припиливаем вывод под наш формат для построения ssa из qbe
>  * считаем это эталонным решением
>  * генерим с помощью него тесты
> Ну а само тестирование просто проверяет что вывод пришедшего решения
> совпадает с тем что мы нагенерили(ну, с поправкой на возможное
> несовпадение порядка)

Это понятно. Я имел в виду тестирование с точки зрения студентов,
которые будут впоследствии решать эту задачу. Им будет удобнее смотреть
на ГПУ в SSA целиком, чем на фи-функции и ГПУ по отдельности.

-- 
Влад