A key job of the IREE compiler and runtime is capturing function call semantics from the originating system and providing mechanisms so that invocations can be performed in as similar way as possible in various target languages. In general, this requires additional metadata on top of the raw characteristics of a function. Where possible, this is done by attaching attributes to a function.
iree.abi : JSON encoded description of the function's calling convention.This is the default ABI supported by the IREE VM invocations. It attempts to provide a default calling convention that can be used without further reflection metadata but which may be enhanced with it.
It natively allows monomorphic functions to be exported where arguments and results are composed of the following types:
ND-Array buffers of Value Types:
String (byte arrays)
Opaque reference object
The intent with these low level types is that calling conventions can be synthesized to bind arbitrary high level, domain/language specific signatures to these types, possibly by way of additional reflection metadata.
The above are all representable with native constructs in the VM:
ValueType:
iree_vm_valueSimple ND-Array Buffer:
iree_hal_buffer_viewtensor<>String:
iree_vm_list containing i8!util.list<i8>Tuple:
iree_vm_list of variant!util.list<?>TypedList (homogenous):
iree_vm_list of T!util.list<T>While the above features of the native ABI may be sufficient for direct use by various programs, many programs and callers will need to represent various higher level types, consistently mapping them to the above facilities. This section describes calling conventions for various higher level types which do not map 1:1 to the above. Not all source language types are representable, and extending these calling conventions (and the fundamental types above) is demand driven.
All of these calling conventions presume that the arity of the arguments/results of the raw function matches the user-level function, meaning that the calling convention is specified per argument/result. Higher-level whole function transformations may also exist for some domains but are outside of the scope of this specification.
A Structure is a common enough entity to have a dedicated calling convention. In C-like languages, this may just be a struct. In Python, it is typically a dict with an associated schema providing a name and type bound for each of its slots. In both, its slots are of fixed arity.
In this convention, such a structure is represented as a Tuple in the native calling convention (i.e. !util.list of variant type). The order of the elements of the tuple are the natural order of the structure, where that is either:
dict) where no order is defined, the natural order will be the lexically sorted order of the keys.Most languages interop between byte arrays (i.e. the native ABI String type) by way of applying an encoding. Such strings are just a sequence of bytes (i.e. !util.list<i8>).
High level lists which all share the same type bound are represented as a TypedList in the native ABI.
NDArrays of reference types are considered separately from those of value types. Internally, the code generated for them is completely different from what gets generated for numeric based arrays (i.e. has ref-counting, ownership semantics, non-POD, etc). These types are permitted for completeness, not necessarily performance: by nature they are already indirected and have overheads.
In the native ABI, these are represented as a composite tuple type (i.e. today a list since sugar for tuple is not yet defined): !iree.tuple<!util.list<T>, !util.list<index>>. The first element of the tuple is the list of values, packed with a C-Layout and the second element is the list of dimension sizes.
Additional reflection metadata may be encoded in a custom JSON form, providing additional typing hints for arguments and results. If present, this will be a reflection attribute with key d, containing a serialized JSON object.
The JSON object contains:
a (array): List of type records for each argument.r (array): List of type records for each argument.Type records are one of:
A string naming a primitive type:
i[0-9]+: Integer type with given bit widthf[0-9]+: IEEE floating point type with given bit widthbf16: BFloat16JSON null: A null reference value
"unknown": An unknown/unmapped type
An array, interpreted as a tuple describing a compound type.
A compound type tuple has a type identifier as its first element, followed with type specific fields:
["named", "key", {slot_type}]: Associates a name with a slot. This is used with the root argument list to denote named arguments that can be passed positionally or by keyword.["ndarray", {element_type}, {rank}, {dim...}]: For unknown rank, the rank will be null and there will be no dims. Any unknown dim will be null.["slist", {slot_type...}]: An anonymous structured list of fixed arity and slot specific types. If there are gaps in the list, empty slots will have a null type.["stuple", {slot_type...}]: Same as slist but some languages differentiate between sequences represented as lists and those represented as tuples (read-only lists).["sdict", ["key", {slot_type}]...]: An anonymous structure with named slots. Note that when passing these types, the keys are not passed to the function (only the slot values).["py_homogeneous_list", {element_type}]: A Python list of unknown size with elements sharing a common type bound given by element_type.