While working on type verifiers in the LLVM dialect, I noticed that we have pairwise-redundant concepts in ODS for types:
TypeConstraintthat contains a predicate checking if a type instance satisfies the constraint and a description;
Typethat derives from TypeConstraint and only defines a duplicate field for the description and provides an empty field for builder (see below);
BuildableTypethat defines the same builder field as
Typewithout being connected to
TypeConstraint. It has been intended for types one can construct given a context and the information present in the ODS description, e.g. standard f32 (only context) or standard integer (context + bitwidth available in the ODS description).
I remember introducing TypeConstraint and can repeat the rationale: conceptually many ODS definitions are not types but constraints. For example, “AnyInteger” or “AnyMemref” do not identify a specific type but rather a condition a given type must satisfy. Yet both inherit from
Type rather than
TypeConstraint. Many core ODS pieces use
Type when they should be actually using
BuildableType was intended for constructing types in ODS-generated code, i.e.
BuildableType actually is a specific type. Declarative assembly relies on this for results.
I propose to (1) replace all uses of
Type that don’t define a concrete type with
TypeConstraint; (2) merge
Type to denote a concrete type, with an optional field for builder code.
Type will keep inheriting from
TypeConstraint and remain usable anywhere a
TypeConstraint is expected.