mirror of
https://github.com/capstone-engine/llvm-capstone.git
synced 2025-02-13 05:40:59 +00:00
bd161ae5bc
In TableGen definitions, the "Type" class has been used for types of things that can be stored in Attributes, but not necessarily present in the MLIR type system. As a consequence, records like "String" or "DerviedAttrBody" were of class "Type", which can be confusing. Furthermore, the "builderCall" field of the "Type" class serves only for attribute construction. Some TableGen "Type" subclasses that correspond to MLIR kinds of types do not have a canonical way of construction only from the data available in TableGen, e.g. MemRefType would require the list of affine maps. This leads to a conclusion that the entities that describe types of objects appearing in Attributes should be independent of "Type": they have some properties "Type"s don't and vice versa. Do not parameterize Tablegen "Attr" class by an instance of "Type". Instead, provide a "constBuilderCall" field that can be used to build an attribute from a constant value stored in TableGen instead of indirectly going through Attribute.Type.builderCall. Some attributes still don't have a "constBuilderCall" because they used to depend on types without a "builderCall". Drop definitions of class "Type" that don't correspond to MLIR Types. Provide infrastructure to define type-dependent attributes and string-backed attributes for convenience. PiperOrigin-RevId: 229570087