It was introduced in the previous MLIR syntax introduction video that one of the characteristics of MLIR is that it proposes the concept of Dialect. The deep learning model is transformed and optimized between the IR of multi-layer Dialect, and finally forms binary files that can run on hardware. The process of converting from one Dialect to another is Conversion.
MLIR provides a Dialect Conversion framework to support this conversion process. In essence, it is to convert a series of illegal operators on the target Dialect into legal operators.
Unlike traditional compilers which can only perform full conversions, MLIR provides a more flexible conversion mode, which can perform both full conversions and partial conversions.
PartialConversion refers to reserving the op that has not been explicitly marked as illegal, and then legalizing the rest of the op as much as possible so that even if there are some unknown op in the original IR, the conversion can be performed; AnalysisConversion will analyze which op can be legalized through partial conversion and record whether the op conversion is successful or not; FullConversion will legalize all ops, so only known op exist in the converted IR.
To use these transformation patterns, users need to prepare the components required for Dialect Conversion. There are three main components:
The first component is Target, which is mainly used to define which operators and Dialects are legal in the conversion process. The actions of operators and Dialects can be marked as legal, dynamic and illegal. Dynamic means that some operators are legal only in some instances.
Users can either create a custom target by inheriting the parent class of ConversionTarget or add legal and illegal Op directly through the function of the add series in the instance of ConversionTarget. In addition, users can also use markOpRecursivelyLegal to define an area, that is, all Op nested in an Op, as legal.
After defining legal and illegal operators, users need to legalize patterns to convert illegal operators into legal operators. Therefore, the rewrite pattern is the transformation logic used to convert illegal operators into legal operators.
The Dialect Conversion framework will automatically generate a conversion diagram based on the provided patterns for legalization, thus simplifying the entire rewrite process. For example, our patterns only mention that the op0 of Dialect A can be legalized as op0 in B, and the op0 in B can be legalized as op0 in C. The Conversion framework will automatically detect that the op0 of Dialect A can be legalized as op0 in Dialect C without intermediate operator conversion.
There is also a special case in RewritePattern, which is ConversionPattern. Compared with the traditional rewritepattern, it has an additional input parameter of operands. This operands array is used to record those remapped operands, mainly used to handle those operators that have type conversion. The operator will operate on the values after type conversion, but it still needs to match the original operands.
When there is a type conversion, the type converter is required to define the conversion method of the type when interacting with the pattern. The type of the remapped operands must be consistent with that stipulated by the type converter. If no type converter is provided, the types of these operands must match the original operands. Otherwise, the pattern application will fail before calling matchAndRewrite to ensure the validity of the type. Therefore, patterns do not need to worry about the security issue of type.
TypeConverter is mainly composed of two aspects, Conversion and Materialization. Both are used to define the conversion method of Type. However, the latter can generate IR and realize the back-and-forth conversion from type according to different requirements in the conversion process. After all the required components above are prepared in the pass of Dialect conversion, IR conversion between Dialects can be realized through the conversion interface.