MLIR (software)

MLIR ( Multi-Level Intermediate Representation ) es un proyecto de infraestructura de compilador de código abierto desarrollado como un subproyecto del proyecto LLVM . Proporciona un marco de representación intermedia (IR) modular y extensible destinado a facilitar la construcción de compiladores específicos de dominio y mejorar la compilación para plataformas de computación heterogéneas . MLIR admite múltiples niveles de abstracción en un solo IR e introduce dialectos , un mecanismo para definir operaciones, tipos y atributos personalizados adaptados a dominios específicos. ^{[ 1 ]} El nombre "Multi-Level Intermediate Representation" refleja la capacidad del sistema para modelar cálculos en varios niveles de abstracción y reducirlos progresivamente hacia el código máquina .

MLIR fue desarrollado originalmente en 2018 por Chris Lattner en Google y lanzado públicamente como parte de LLVM en 2019. ^{[ 2 ]} Fue diseñado para abordar los desafíos en la creación de compiladores para cargas de trabajo modernas como aprendizaje automático , aceleración de hardware y síntesis de alto nivel , proporcionando componentes reutilizables y estandarizando la representación de cálculos intermedios en diferentes lenguajes de programación y objetivos de hardware. ^{[ 1 ] [ 3 ]}

MLIR se utiliza en una variedad de sistemas, incluidos TensorFlow , Mojo , TPU-MLIR y otros. ^{[ 4 ]} Se publica bajo la Licencia Apache 2.0 con excepciones LLVM y se mantiene como parte del proyecto LLVM. ^{[ 1 ]}

El trabajo en MLIR comenzó en 2018, liderado por Chris Lattner en Google en colaboración con Mehdi Amini, River Riddle y otros, como respuesta a la creciente complejidad de las cadenas de herramientas de compilación modernas. ^{[ 1 ] [ 2 ]} El proyecto tenía como objetivo mejorar la modularidad, la componibilidad y la mantenibilidad de las infraestructuras de compilación, particularmente en dominios como el aprendizaje automático , la síntesis de alto nivel y la aceleración de hardware . Fue presentado formalmente en la Reunión de Desarrolladores de LLVM de 2019 y se publicó como código abierto más tarde ese mismo año como parte del monorepositorio de LLVM. ^{[ 5 ] [ 6 ]}

La arquitectura de MLIR se basó en experiencias previas en la creación de compiladores como XLA y LLVM , donde las limitaciones de las representaciones intermedias existentes dificultaban la optimización y la reutilización entre los distintos niveles de abstracción. Para solucionar esto, MLIR introdujo un concepto novedoso de representaciones intermedias multinivel que podían coexistir en el mismo sistema y reducirse gradualmente mediante transformaciones bien definidas. Una característica fundamental del diseño fue el uso de dialectos , que permitían a diferentes dominios y plataformas de hardware definir operaciones y sistemas de tipos personalizados, manteniendo la interoperabilidad. ^{[ 2 ]}

Desde su lanzamiento, MLIR ha sido adoptado por diversos ecosistemas de compiladores y proyectos de investigación. En TensorFlow , MLIR sirve como base para la reescritura y la reducción de transformaciones en componentes como XLA y TensorFlow Runtime . El lenguaje Mojo , desarrollado por Modular Inc., se basa en MLIR para lograr la compilación anticipada en cargas de trabajo de inteligencia artificial. ^{[ 3 ]} Otros proyectos que se han basado en MLIR incluyen TPU-MLIR para compilar modelos en hardware de Tensor Processing Unit , ^{[ 7 ]} ONNX-MLIR para modelos de aprendizaje automático interoperables, ^{[ 8 ]} MLIR-AIE para Xilinx AI Engines, ^{[ 9 ]} IREE para compilar y ejecutar modelos de aprendizaje automático en CPU, GPU y aceleradores, ^{[ 10 ]} DSP-MLIR, una infraestructura de compilación adaptada para aplicaciones de procesamiento de señales digitales (DSP), ^{[ 11 ]} y torch-mlir, que aporta capacidades de compilación basadas en MLIR al ecosistema PyTorch . ^{[ 12 ] [ 4 ]}

MLIR continúa evolucionando como parte del Proyecto LLVM y se rige por su calendario de lanzamientos y políticas de desarrollo. Su desarrollo es fruto de la colaboración de expertos de la industria, el mundo académico y la comunidad de código abierto en general.

En MLIR, un dialecto define un espacio de nombres autocontenido de operaciones, tipos, atributos y otras construcciones. Los dialectos son el mecanismo principal de extensibilidad, lo que permite a los desarrolladores introducir abstracciones específicas del dominio manteniendo la compatibilidad dentro del marco general de MLIR. Cada operación dentro de un dialecto se identifica mediante un nombre único y puede incluir operandos, resultados, atributos y regiones opcionales. Los operandos y los resultados siguen el formato de asignación única estática (SSA), y cada resultado está asociado a un tipo. Los atributos representan metadatos en tiempo de compilación, como valores constantes. Las regiones consisten en bloques ordenados, cada uno de los cuales puede tomar argumentos de entrada y contener una secuencia de operaciones anidadas. ^{[ 13 ]} Si bien MLIR está diseñado en torno a SSA, evita los nodos PHI tradicionales al utilizar argumentos de bloque junto con los operandos de las operaciones de flujo de control para modelar la fusión de valores. ^{[ 14 ]}

La sintaxis general para una operación es la siguiente:

% res : 2 = "mydialect.morph" ( % input # 3 ) ({ ^ bb0 ( % arg0 : !mydialect < "custom_type" > loc ( "mysource.cc" : 10 : 8 )): // operaciones anidadas }) { some . attribute = true , other_attribute = 1 . 5 } : ( !mydialect < "custom_type" >) -> ( !mydialect < "other_type" >, !mydialect < "other_type" >) loc ( callsite ( "foo" at "mysource.cc" : 10 : 8 ))

Esta operación, denominada morph, pertenece al mydialectdialecto. Recibe un operando de entrada ( %input#3) de tipo custom_typey produce dos valores de salida de tipo other_type. La operación incluye dos atributos: some.attributey other_attribute, y contiene una región con un único bloque ( ^bb0) que acepta un argumento. La locpalabra clave especifica información de ubicación a nivel de código fuente, que puede utilizarse para la depuración o la generación de informes de diagnóstico. ^{[ 15 ]}

La sintaxis de las operaciones, los tipos y los atributos también se puede personalizar según las preferencias del usuario mediante la implementación de funciones adecuadas de análisis y impresión dentro de la definición de la operación. ^{[ 16 ]}

El ecosistema de dialectos de MLIR es abierto y extensible, lo que permite a los usuarios finales definir nuevos dialectos que capturen la semántica de dominios computacionales específicos. Al mismo tiempo, el código fuente de MLIR proporciona una variedad de dialectos integrados que abordan patrones comunes que se encuentran en las representaciones intermedias . Estos dialectos centrales están diseñados para ser autocontenidos e interoperables, lo que los hace adecuados para su reutilización en diferentes pilas de compiladores . ^{[ 17 ]}

Por ejemplo, el arithdialecto incluye operaciones matemáticas básicas sobre enteros y tipos de punto flotantememref , mientras que proporciona operaciones para la asignación y el acceso a la memoria. Las abstracciones del flujo de control se manejan mediante dialectos como affine, que admite anidamientos de bucles afines adecuados para la optimización poliédrica , y , que proporciona un flujo de control estructurado utilizando construcciones como , , y . El dialecto admite definiciones y llamadas de funciones, mientras que introduce primitivas para modelos de programación de GPU . Además, define un conjunto de operadores portátil y compatible con la cuantización para la inferencia de aprendizaje automático . Finalmente, proporciona una asignación uno a uno a LLVM IR , lo que permite una conversión fluida al backend de LLVM y la reutilización de su infraestructura de optimización y generación de código. ^{[ 4 ]}scfforifwhilefuncgputosallvm

El siguiente código define una función que toma dos matrices de punto flotante y realiza la suma entre los valores en las mismas posiciones:

func . func @matrix_add ( %arg0: memref <10x20xf32> , %arg1: memref <10x20xf32> ) -> memref <10x20xf32> { %result = memref . alloc () : memref <10x20xf32>afín . para %i = 0 a 10 { afín . para %j = 0 a 20 { %lhs = memref.load %arg0 [ % i , %j ] : memref <10x20xf32> % rhs = memref.load %arg1 [ % i , %j ] : memref <10x20xf32> %sum = arith.addf %lhs , % rhs  : f32 memref.store %sum , % result [ % i , % j ] : memref <10x20xf32> } } func . return %result  : memref <10x20xf32> } 

Aunque se pueden usar diferentes dialectos para expresar cálculos similares, el nivel de abstracción y el flujo de compilación previsto pueden variar. En el ejemplo anterior, el affinedialecto permite el análisis y la optimización de poliedros, mientras que los dialectos memrefy arithexpresan operaciones de memoria y aritméticas, respectivamente. ^{[ 17 ]}

Las operaciones de un dialecto se pueden definir utilizando el lenguaje C++ , pero también de una manera más conveniente y robusta mediante la especificación de definición de operaciones (ODS). ^{[ 18 ]} Mediante TableGen, el código C++ para las declaraciones y definiciones se puede generar automáticamente. ^{[ 19 ]}

El código autogenerado puede incluir métodos de análisis e impresión, que se basan en una cadena simple que mapea la estructura de la representación textual deseada, junto con todo el código repetitivo para acceder a los campos y realizar acciones comunes como la verificación de la semántica de cada operación, la canonización o el plegado . ^{[ 20 ]}

El mismo mecanismo de declaración puede utilizarse también para tipos y atributos, que son las otras dos categorías de elementos que constituyen un dialecto. ^{[ 20 ]}

El siguiente ejemplo ilustra cómo especificar el formato de ensamblaje de una operación que espera un número variable de operandos y produce cero resultados. La representación textual consiste en la lista opcional de atributos, seguida de la lista opcional de operandos, dos puntos y los tipos de los operandos. ^{[ 18 ]}

let assemblyFormat = "attr-dict ($operands^ `:` type($operands))? ;

Las transformaciones siempre se pueden realizar directamente en el IR, sin necesidad de depender de mecanismos de coordinación integrados. Sin embargo, para facilitar tanto la implementación como el mantenimiento, MLIR proporciona una infraestructura para la reescritura del IR compuesta por diferentes controladores de reescritura. Cada controlador recibe un conjunto de objetos denominados patrones , cada uno con su propia lógica interna para relacionar operaciones con ciertas propiedades. Cuando se encuentra una coincidencia con una operación, se realiza el proceso de reescritura y el IR se modifica según la lógica del patrón. ^{[ 21 ]}

Este controlador opera según la legalidad de las operaciones existentes, lo que significa que recibe un conjunto de reglas que determinan qué operaciones deben considerarse ilegales y espera que los patrones coincidan y las conviertan en operaciones legales . La lógica detrás de esas reglas puede ser arbitrariamente compleja: puede basarse simplemente en el dialecto al que pertenecen las operaciones, pero también puede inspeccionar propiedades más específicas como atributos u operaciones anidadas. ^{[ 22 ]}

Como su nombre indica, este controlador se utiliza normalmente para convertir las operaciones de un dialecto en operaciones pertenecientes a otro diferente. En este caso, todo el dialecto de origen se marcaría como no válido, el de destino como válido y se proporcionarían patrones para las operaciones del dialecto de origen. El marco de conversión de dialectos también admite la conversión de tipos , que debe realizarse en los operandos y resultados para convertirlos al sistema de tipos del dialecto de destino. ^{[ 22 ]}

MLIR permite tomar múltiples rutas de conversión. Considerando el ejemplo sobre la suma de matrices, una posible estrategia de reducción podría ser generar bucles for pertenecientes al dialecto scf , obteniendo código para ser ejecutado en las CPU :

#map = mapa_afín<(d0, d1) -> (d0, d1)>módulo { func . func @avg ( %arg0: memref <10x20xf32> , %arg1: memref <10x20xf32> ) -> memref <10x20xf32> { %alloc = memref . alloc () : memref <10x20xf32>%c0 = aritmética . constante 0  : índice%c10 = aritmética . constante 10  : índice%c1 = aritmética . constante 1  : índicescf . para %arg2 = %c0 a %c10 paso %c1 { %c0_0 = aritmética . constante 0  : índice % c20 = aritmética.constante 20 : índice​%c1_1 = aritmética . constante 1  : índicescf . para %arg3 = %c0_0 hasta %c20 paso %c1_1 { %0 = referenciamem . cargar %arg0 [ %arg2 , %arg3 ] : memref <10x20xf32>%1 = referenciamem . cargar %arg1 [ %arg2 , %arg3 ] : memref <10x20xf32>% 2 = aritm.addf %0 , % 1  : f32memref . almacenar %2 , %alloc [ %arg2 , %arg3 ] : memref <10x20xf32> }  } return %alloc  : memref <10x20xf32> } } 

Otra estrategia posible, sin embargo, podría haber sido utilizar el dialecto de GPU para generar código para GPU :

#map = mapa_afín<(d0, d1) -> (d0, d1)>módulo { func . func @avg ( %arg0: memref <10x20xf32> , %arg1: memref <10x20xf32> ) -> memref <10x20xf32> { %alloc = memref . alloc () : memref <10x20xf32>%c0 = aritmética . constante 0  : índice%c10 = aritmética . constante 10  : índice%0 = aritmética . subi %c10 , %c0  : índice%c1 = aritmética . constante 1  : índice%c0_0 = aritmética . constante 0  : índice % c20 = aritmética.constante 20 : índice​%1 = aritmética . subi %c20 , %c0_0  : índice%c1_1 = aritmética . constante 1  : índice%c1_2 = aritmética . constante 1  : índicegpu . launch blocks ( %arg2 , %arg3 , %arg4 ) in ( %arg8 = %0 , %arg9 = %c1_2 , %arg10 = %c1_2 ) threads ( %arg5 , %arg6 , %arg7 ) in ( %arg11 = %1 , %arg12 = %c1_2 , %arg13 = %c1_2 ) { %2 = aritmética . addi %c0 , %arg2  : índice%3 = aritmética . addi %c0_0 , %arg5  : índice%4 = memref . load %arg0 [ %2 , %3 ] : memref <10x20xf32>%5 = memref . cargar %arg1 [ %2 , %3 ] : memref <10x20xf32>% 6 = aritmético.addf % 4 , %5  : f32memref . almacenar %4 , %alloc [ %2 , %3 ] : memref <10x20xf32>GPU . Terminador } return %alloc  : memref <10x20xf32> } } 

El controlador aplica de forma voraz los patrones proporcionados según su beneficio, hasta que se alcanza un punto fijo o el número máximo de iteraciones. El beneficio de un patrón se autoatribuye. En caso de igualdad, se utiliza el orden relativo dentro de la lista de patrones. ^{[ 21 ]}

MLIR permite aplicar optimizaciones existentes (por ejemplo, eliminación de subexpresiones comunes , movimiento de código invariante a bucles ) en dialectos personalizados mediante rasgos e interfaces. Estos dos mecanismos permiten que los pases de transformación operen sobre operaciones sin conocer su implementación real, basándose únicamente en algunas propiedades que proporcionan los rasgos o las interfaces. ^{[ 23 ] [ 24 ]}

Los rasgos están diseñados para adjuntarse a las operaciones sin requerir ninguna implementación adicional. Su propósito es indicar que la operación satisface ciertas propiedades (por ejemplo, tener exactamente dos operandos). ^{[ 23 ]} Las interfaces, en cambio, representan una herramienta más potente mediante la cual se puede consultar la operación acerca de algún aspecto específico, cuyo valor puede cambiar entre instancias del mismo tipo de operación. Un ejemplo de interfaz es la representación de efectos de memoria: cada operación que opera sobre la memoria puede tener dicha interfaz adjunta, pero los efectos reales pueden depender de los operandos reales (por ejemplo, una llamada a función con argumentos que posiblemente sean constantes o referencias a la memoria). ^{[ 24 ]}

La libertad en el modelado de representaciones intermedias permite que MLIR se utilice en una amplia gama de escenarios. Esto incluye lenguajes de programación tradicionales, ^{[ 25 ]} pero también síntesis de alto nivel , ^{[ 26 ] [ 27 ]} computación cuántica ^{[ 28 ]} y cifrado homomórfico . ^{[ 29 ] [ 30 ] [ 31 ]} Las aplicaciones de aprendizaje automático también aprovechan las técnicas de compilación poliédrica integradas, junto con dialectos dirigidos a aceleradores y otros sistemas heterogéneos . ^{[ 32 ] [ 33 ] [ 34 ] [ 35 ] [ 36 ]}

Para proyectos de compiladores y cadenas de herramientas específicas creadas con MLIR, consulte la sección Ecosistema a continuación.

MLIR ha impulsado un ecosistema creciente de proyectos de código abierto, compiladores de producción y cadenas de herramientas experimentales en múltiples ámbitos. Estos proyectos demuestran la flexibilidad de MLIR para modelar, optimizar y reducir los cálculos en una amplia gama de plataformas de hardware.

TensorFlow/XLA integra MLIR como un componente fundamental de su moderna infraestructura de compilación . MLIR se utiliza para representar los grafos de computación de TensorFlow en una forma intermedia extensible , lo que facilita transformaciones como la fusión, la cuantización y la reducción específica del backend. Tanto el compilador TensorFlow Runtime (TFRT) como el compilador Accelerated Linear Algebra (XLA) se basan en MLIR para mejorar la portabilidad y el rendimiento en diferentes plataformas de hardware . ^{[ 4 ] [ 37 ] [ 38 ] [ 39 ] [ 40 ]}

IREE (Intermediate Representation Execution Environment) es un compilador y sistema de ejecución integral construido completamente sobre MLIR. Compila modelos de aprendizaje automático de alto nivel , como los de TensorFlow y TensorFlow Lite, en ejecutables portátiles y optimizados que pueden ejecutarse en diversos sistemas de hardware, incluyendo CPU , GPU y aceleradores dedicados . IREE admite flujos de trabajo de compilación anticipada (AOT) y justo a tiempo (JIT) , y sirve como demostración de cómo MLIR puede funcionar como la representación intermedia para una pila de compilación completa , abarcando la reducción del frontend, la optimización, la generación de código del backend y la ejecución en tiempo de ejecución . ^{[ 41 ] [ 42 ] [ 43 ] [ 44 ]}

torch-mlir es un proyecto de compilador que integra infraestructura basada en MLIR en el ecosistema PyTorch . Introduce dialectos Torch y TorchCoversion que modelan abstracciones a nivel de PyTorch, como TorchScript y la semántica del modo eager, y proporciona pasos de transformación para reducir progresivamente estas representaciones hacia objetivos optimizados para hardware. torch-mlir está diseñado para ser un marco de trabajo de backend modular, que permite una ejecución de alto rendimiento en diversas plataformas, incluyendo CPU , GPU y aceleradores especializados . ^{[ 12 ] [ 45 ] [ 46 ] [ 47 ]}

ONNX-MLIR es un marco de compilación basado en MLIR que se dirige al ecosistema ONNX . Proporciona una canalización de conversión y optimización para modelos ONNX traduciéndolos a MLIR mediante una serie de dialectos específicos que representan operaciones ONNX y formas intermedias. ONNX-MLIR permite la ejecución en una amplia gama de plataformas de hardware aprovechando la infraestructura de reducción extensible y la integración de backend de MLIR. El proyecto admite la importación de modelos, la inferencia de formas y la generación de código para múltiples destinos, y sirve como implementación de referencia para la compilación de ONNX a MLIR. ^{[ 48 ] [ 8 ] [ 49 ]}

MLIR-AIE es un marco de compilación desarrollado por Xilinx para programar matrices AI Engine (AIE) presentes en las plataformas Versal ACAP . Extiende MLIR con dialectos personalizados y pasos de transformación adaptados a la arquitectura de flujo de datos y las restricciones de compilación del hardware AIE. MLIR-AIE permite a los desarrolladores de software escribir programas de alto nivel y compilarlos en conjuntos de instrucciones optimizados, adecuados para cargas de trabajo profundamente integradas, paralelas y con planificación estática. El marco admite pipelines específicos de hardware, como IRON y AIR, para las plataformas AMD Ryzen AI y Versal-AIE. ^{[ 9 ] [ 50 ] [ 51 ] [ 52 ]}

Triton-MLIR es una infraestructura de compilación que incorpora herramientas basadas en MLIR al modelo de programación Triton , utilizado para escribir kernels de GPU personalizados de alta eficiencia . Introduce dialectos MLIR que representan las abstracciones centrales de Triton, incluyendo bloques, warps y espacios de memoria, y los integra con las canalizaciones de transformación MLIR existentes. Triton-MLIR habilita nuevas vías para la optimización, la interoperabilidad y la extensibilidad del backend dentro del ecosistema Triton. También forma parte del esfuerzo más amplio de Microsoft para unificar la representación del kernel de Triton bajo la arquitectura del compilador MLIR. ^{[ 53 ] [ 54 ] [ 55 ] [ 56 ]}

Mojo es un lenguaje de programación de sistemas desarrollado por Modular Inc. que integra la sintaxis de Python con características de rendimiento de bajo nivel. Mojo se basa en MLIR y lo utiliza como su marco de representación intermedia principal. El lenguaje define dialectos personalizados para admitir características de compilación avanzadas como tipado estático, control de la disposición de la memoria, metaprogramación y especialización de hardware. MLIR permite que Mojo interactúe sin problemas con otros sistemas basados ​​en MLIR y genere código altamente optimizado para una amplia gama de aceleradores y plataformas heterogéneas. ^{[ 57 ] [ 58 ] [ 59 ] [ 3 ]}

• LLVM
• TensorFlow
• Unidad de procesamiento tensorial

• Sitio web oficial
• MLIR en GitHub , código fuente
• Documentación del código