'dlti' Dialect

The Data Layout and Target Information (DLTI) dialect is intended to hold attributes and other components pertaining to descriptions of in-memory data layout and compilation targets.

Attributes ¶

DataLayoutEntryAttr ¶

An attribute to represent an entry of a data layout specification.

A data layout entry attribute is a key-value pair where the key is a type or an identifier and the value is another attribute. These entries form a data layout specification.

Parameters: ¶

DataLayoutSpecAttr ¶

An attribute to represent a data layout specification.

A data layout specification is a list of entries that specify (partial) data layout information. It is expected to be attached to operations that serve as scopes for data layout requests.

Parameters: ¶

FunctionPointerAlignmentAttr ¶

An attribute to represent function pointer alignment.

Syntax:

#dlti.function_pointer_alignment<
  uint64_t,   # alignment
  bool   # function_dependent
>

Function pointer alignment specifies the minimum alignment of function pointers, it’s a multiple of alignment. This alignment can also depend on the target function, indicated by function_dependent. Example:

#dlti.dl_entry<"dlti.function_pointer_alignment",
           #dlti.function_pointer_alignment<64, function_dependent = false>>

Parameters: ¶

MapAttr ¶

A mapping of DLTI-information by way of key-value pairs

A Data Layout and Target Information map is a list of entries effectively encoding a dictionary, mapping DLTI-related keys to DLTI-related values.

This attribute facilitates queries for arbitrary DLTI key-value associations. An operation can store it in its inherent dlti attribute and expose its entries through DLTIQueryOpInterface. Query results that implement DLTIQueryInterface can be queried recursively.

Consider the following flat encoding of a single-key dictionary

#dlti.map<"CPU::cache::L1::size_in_bytes" = 65536 : i32>

versus nested maps, which make it possible to obtain sub-dictionaries of related information (with the following example making use of other attributes that also implement the DLTIQueryInterface):

#dlti.target_system_spec<"CPU" =
  #dlti.target_device_spec<"cache" =
    #dlti.map<"L1" = #dlti.map<"size_in_bytes" = 65536 : i32>,
              "L1d" = #dlti.map<"size_in_bytes" = 32768 : i32> >>>

With the flat encoding, the implied structure of the key is ignored, that is the only successful query (as expressed in the Transform Dialect) is: transform.dlti.query ["CPU::cache::L1::size_in_bytes"] at %op, where %op handles an operation with the flat #dlti.map stored as its inherent dlti attribute.

For querying nested dictionaries, the relevant keys need to be separately provided. If %op handles an operation with the nested #dlti.target_system_spec above as its inherent dlti attribute, then transform.dlti.query ["CPU","cache","L1","size_in_bytes"] at %op gives back the first leaf value contained. To access the other leaf, we need to do transform.dlti.query ["CPU","cache","L1d","size_in_bytes"] at %op.

Parameters: ¶

TargetDeviceSpecAttr ¶

An attribute to represent target device specification.

Each device specification describes a single device and its hardware properties. Each device specification can contain any number of optional hardware properties (e.g., max_vector_op_width below).

Example:

#dlti.target_device_spec<"max_vector_op_width" = 64 : ui32>

Parameters: ¶

TargetSystemSpecAttr ¶

An attribute to represent target system specification.

A system specification describes the overall system containing multiple devices, with each device having a unique ID (string) and its corresponding TargetDeviceSpec object.

Example:

dlti.target_system_spec =
 #dlti.target_system_spec<
  "CPU" = #dlti.target_device_spec<
    "L1_cache_size_in_bytes" = 4096: ui32>,
  "GPU" = #dlti.target_device_spec<
    "max_vector_op_width" = 64 : ui32>,
  "XPU" = #dlti.target_device_spec<
    "max_vector_op_width" = 4096 : ui32>>

The verifier checks that keys are strings and pointed to values implement DLTI’s TargetDeviceSpecInterface.

Parameters: ¶