Работа с LLVM

В Julia в настоящее время применяется анализ псевдонимов на основе типов LLVM. Найти комментарии, в которых документируются отношения включения, можно по static MDNode* в файле src/codegen.cpp.

Параметр -O включает базовый анализ псевдонимов LLVM.

Таким образом, главная сложность заключается в выборе представления IR, которое позволяет определять указатели, отслеживаемые сборщиком мусора, и случаи их использования даже после прогона программы через оптимизатор. Для этого наш подход предполагает использование трех функций LLVM:

Пользовательские адресные пространства позволяют нам пометить целым числом каждое место, которое должно сохраняться в процессе оптимизаций. Компилятор не может добавлять приведения между адресными пространствами, которых не было в исходной программе, и никогда не должен изменять адресное пространство указателя при операции загрузки, сохранения и т. д. Это позволяет аннотировать указатели, отслеживаемые сборщиком мусора, так, чтобы на это не мог влиять оптимизатор. Обратите внимание, что реализовать то же самое с помощью метаданных невозможно. Предполагается, что любые метаданные можно удалить без изменения смысла программы. Однако невозможность определить указатель, отслеживаемый сборщиком мусора, коренным образом меняет поведение программы — она может завершаться сбоем или возвращать неверные результаты. В настоящее время мы используем три разных адресных пространства (их номера определены в файле src/codegen_shared.cpp):

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

Во-первых, разрешены только следующие приведения адресных пространств:

Теперь давайте рассмотрим, что относится к случаям использования:

Мы явным образом разрешаем операции загрузки и сохранения и простые вызовы в адресных пространствах Tracked и Derived. Элементы массивов аргументов jlcall всегда должны находиться в адресном пространстве Tracked (согласно ABI они должны быть действительными указателями jl_value_t*). То же самое верно для инструкций return (однако обратите внимание, что возвращаемые аргументы в виде структур могут находиться в любом адресном пространстве). Единственный допустимый вариант использования указателя в адресном пространстве CalleeRooted — его передача в вызов (который должен иметь операнд соответствующего типа).

Кроме того, запрещено нахождение getelementptr в адресном пространстве Tracked. Причина в том, что если операция не является холостой, указатель в итоге будет невозможно сохранить в слоте сборки мусора и поэтому он не сможет находиться в этом адресном пространстве. Если такой указатель требуется, его сначала нужно привести к адресному пространству Derived.

Наконец, в этих адресных пространствах запрещены инструкции inttoptr и ptrtoint. Наличие таких инструкций означало бы, что некоторые значения i64 на самом деле отслеживаются сборщиком мусора. А это создавало бы проблему, так как нарушало бы требование возможности определения указателей, имеющих отношение к сборке мусора. Данный инвариант обеспечивается функцией «нецелочисленных указателей» LLVM, которая появилась в LLVM 5.0. Она запрещает оптимизатору производить оптимизации, которые привели бы к появлению таких операций. Обратите внимание: мы по-прежнему можем вводить статические константы во время JIT с помощью inttoptr в адресном пространстве 0, а затем приводить их к соответствующему адресному пространству.

Важным аспектом, который пока не обсуждался, является обработка ccall. Особенностью ccall является то, что место и область использования не совпадают. Рассмотрим следующий пример:

При понижении добавляет преобразование массива в указатель, в результате чего удаляется ссылка на значение массива. Однако, безусловно, необходимо сделать так, чтобы массив оставался активен, пока выполняется ccall. Чтобы понять, как это достигается, сначала вспомним, как понижается приведенный выше код:

Последний элемент :(A) — это дополнительный список аргументов, который добавляется во время понижения и сообщает генератору кода, какие значения на уровне Julia должны оставаться активными на протяжении выполнения этого ccall. Затем мы берем эту информацию и представляем ее в виде «пакета операндов» на уровне IR. Пакет операндов — это по сути фиктивный случай использования, привязываемый к месту вызова. На уровне IR это выглядит так:

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

Особенностью pointer_from_objref является то, что пользователь должен явно контролировать корни сборки мусора. Согласно приведенным выше инвариантам эта функция недопустима, так как она выполняет приведение из адресного пространства 10 в 0. Однако в некоторых ситуациях она может быть полезна, поэтому мы предоставляем специальную внутреннюю функцию:

Она понижается до соответствующего приведения адресного пространства после понижения корней сборки мусора. Однако обратите внимание, что, используя эту внутреннюю функцию, вызывающая сторона берет на себя всю ответственность за то, чтобы значение было корневым. Кроме того, данная внутренняя функция не считается случаем использования, поэтому во время прохода размещения корней сборки мусора корень сборки мусора для нее не предоставляется. В результате необходимо обеспечить внешний контроль корней, пока значение отслеживается системой. То есть недопустимо пытаться использовать результат этой операции для создания глобального корня — оптимизатор мог уже удалить значение.

В некоторых случаях объект должен оставаться активным, даже если компилятору неизвестны случаи его использования. Это может быть справедливо в случае с низкоуровневым кодом, который напрямую оперирует с представлением объекта в памяти, или с кодом, который должен взаимодействовать с кодом C. Для этого мы предоставляем следующие внутренние функции на уровне LLVM:

(Элемент llvm. необходим для использования типа token.) Эти внутренние функции имеют следующий смысл: в любой безопасной точке, которой управляет вызов gc_preserve_begin, но не управляет соответствующий вызов gc_preserve_end (то есть вызов, аргументом которого является токен, возвращаемый вызов gc_preserve_begin), значения, передаваемые как аргументы в этот вызов gc_preserve_begin, будут оставаться активными. Имейте в виду, что gc_preserve_begin по-прежнему считается обычным случаем использования этих значений, поэтому стандартная семантика времени существования будет обеспечивать активность значений до входа в область сохранения.