Пользовательские проходы LLVM

Этот проход снижает значение внутренней функции julia.cpu.have_fma.(f32|f64) до true или false в зависимости от целевой архитектуры и целевых особенностей, присутствующих в функции. Эта внутренняя функция часто используется для определения того, насколько использование алгоритмов, зависящих от быстрых операций объединенного умножения-сложения, лучше, чем использование стандартных алгоритмов, не зависящих от таких инструкций.

Этот проход заменяет операции float16 операциями float32 в архитектурах, изначально не поддерживающих операции float16. Для этого нужно вставить инструкции fpext и fptrunc вокруг любой операции float16. В архитектурах, поддерживающих собственные операции float16, этот проход не работает.

Этот проход выполняет большую часть работы с корнями сборки мусора, необходимой для отслеживания указателей между точками безопасности сборки мусора. Он также снижает уровень нескольких внутренних функций до соответствующего преобразования инструкции и может нарушать установленные ранее нецелочисленные инварианты (pointer_from_objref здесь понижается до инструкции ptrtoint). Этот проход обычно длится дольше всех пользовательских проходов Julia из-за алгоритма потока данных, минимизирующего количество объектов, находящихся в любой безопасной точке.

Этот проход снижает уровень нескольких последних внутренних функций до их окончательного варианта с нацеливанием на функции в библиотеке libjulia. Отделение этого прохода от LateGCLowering позволяет другим бэкендам (компиляция GPU) предоставлять собственные понижения для этих внутренних функций, чтобы конвейер Julia можно было использовать и на этих бэкендах.

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

Эта передача удаляет нецелочисленные адресные пространства из строки datalayout модуля. В этом случае бэкенд может снижать уровень пользовательских адресных пространств Julia непосредственно в машинный код без дорогостоящего переписывания каждой операции с указателем на адресное пространство 0.

Этот проход выступает в качестве основного движущего фактора аннотации @simd. Генерация кода вставляет маркер !llvm.loopid в заднюю ветвь цикла, который в этом проходе используется для идентификации циклов, которые изначально были помечены @simd. Затем этот проход ищет цепочку операций с плавающей запятой, которые образуют reduce, и добавляет флаги contract и reassoc быстрой математики, чтобы разрешить выполнение повторной связи (и, следовательно, векторизации). Этот проход не сохраняет ни информацию о цикле, ни корректность выводов, поэтому может неожиданным образом нарушать семантику Julia. Если цикл также был аннотирован ivdep, то проход помечает его как не имеющий циклически порожденных зависимостей (результирующее поведение будет неопределенным, если пользовательская аннотация была неверной или применена не к тому циклу).

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

Если при генерации кода создается функция с аргументом swiftself и соглашением о вызове, этот проход предполагает, что аргумент swiftself является pgcstack, и заменит внутреннюю функцию с этим аргументом. Это позволяет ускорить работу в архитектурах с медленным доступом к локальному для потоков хранилищу.

Этот проход переименовывает указатели в одном адресном пространстве в другое адресное пространство. Это используется для удаления из IR LLVM относящихся к Julia адресных пространств.

Этот проход удаляет адресные пространства, специфичные для Julia, из IR LLVM. В основном он используется для отображения IR LLVM в более простом формате. Внутренним образом этот проход реализован на основе прохода RemoveAddrspaces.

Этот проход вносит изменения в модуль для создания функций, оптимизированных для работы в разных архитектурах (подробнее см. в sysimg.md и pkgimg.md). С точки зрения реализации он клонирует функции и применяет к ним различные атрибуты, специфичные для конкретной платформы, чтобы оптимизатор мог использовать расширенные возможности, такие как векторизация и планирование инструкций для данной платформы. Он также создает определенную инфраструктуру, позволяющую загрузчику образов Julia выбирать подходящую версию функции для вызова в зависимости от архитектуры, на которой работает этот загрузчик. Атрибутами, специфичными для целевого объекта, управляет флаг модуля julia.mv.specs, который при компиляции извлекается из переменной среды JULIA_CPU_TARGET. Для активации прохода необходимо установить флаг модуля julia.mv.enable со значением 1.

Этот проход используется для проверки инвариантов Julia относительно IR LLVM. Сюда входят, например несуществование ptrtoint в нецелочисленных адресных пространствах Julia ^[1] и существование только одобренных инструкций nislides (Tracked -> Derived, 0 -> Tracked и т. д.). Он не выполняет никаких преобразований в IR.

Этот проход служит для оптимизации конкретного сочетания обычной функции fmul с быстрой функцией fadd в сжатую функцию fmul с быстрой функцией fadd. Впоследствии бэкенд оптимизирует этот вариант в инструкцию объединенного умножения-сложения для значительного ускорения операций ценой более непредсказуемой семантики.

В Julia нет понятия программного стека как места для выделения изменяемых объектов. Однако выделение объектов в стеке снижает нагрузку на сборку мусора и очень важно для компиляции на графических процессорах. Таким образом, AllocOpt выполняет преобразование из кучи в стек для объектов, которые, как он может доказать, не выходят из текущей функции. Он также выполняет ряд других оптимизаций выделений, например удаляет выделения, которые никогда не используются, оптимизирует вызовы typeof к только что выделенным объектам и удаляет сохранения в выделениях, которые сразу же перезаписываются. Реализация escape-анализа находится в файле llvm-alloc-helpers.cpp. Сейчас этот проход не использует информацию из EscapeAnalysis.jl, но эта ситуация может измениться в будущем.

Этот проход используется для распространения относящихся к Julia адресных пространств в ходе операций с указателями. LLVM не может вводить или удалять инструкции addrspacecast с помощью оптимизаций, поэтому этот проход служит для устранения избыточных инструкций addrspacecast, заменяя операции их аналогом в адресном пространстве Julia. Дополнительные сведения об адресных пространствах Julia см. (ссылка TODO на llvm.md).

Этот проход используется для вывода относящихся к Julia внутренних функций из циклов. В частности, он выполняет следующие преобразования.