'llvm' Dialect

This dialect maps LLVM IR into MLIR by defining the corresponding operations and types. LLVM IR metadata is usually represented as MLIR attributes, which offer additional structure verification.

We use “LLVM IR” to designate the intermediate representation of LLVM and “LLVM dialect” or “LLVM IR dialect” to refer to this MLIR dialect.

Unless explicitly stated otherwise, the semantics of the LLVM dialect operations must correspond to the semantics of LLVM IR instructions and any divergence is considered a bug. The dialect also contains auxiliary operations that smoothen the differences in the IR structure, e.g., MLIR does not have phi operations and LLVM IR does not have a constant operation. These auxiliary operations are systematically prefixed with mlir, e.g. llvm.mlir.constant where llvm. is the dialect namespace prefix.

Dependency on LLVM IR ¶

LLVM dialect is not expected to depend on any object that requires an LLVMContext, such as an LLVM IR instruction or type. Instead, MLIR provides thread-safe alternatives compatible with the rest of the infrastructure. The dialect is allowed to depend on the LLVM IR objects that don’t require a context, such as data layout and triple description.

Module Structure ¶

IR modules use the built-in MLIR ModuleOp and support all its features. In particular, modules can be named, nested and are subject to symbol visibility. Modules can contain any operations, including LLVM functions and globals.

Data Layout and Triple ¶

An IR module may have an optional data layout and triple information attached using MLIR attributes llvm.data_layout and llvm.triple, respectively. Both are string attributes with the same syntax as in LLVM IR and are verified to be correct. They can be defined as follows.

module attributes {llvm.data_layout = "e",
                   llvm.target_triple = "aarch64-linux-android"} {
  // module contents
}

Functions ¶

LLVM functions are represented by a special operation, llvm.func, that has syntax similar to that of the built-in function operation but supports LLVM-related features such as linkage and variadic argument lists. See detailed description in the operation list below.

PHI Nodes and Block Arguments ¶

MLIR uses block arguments instead of PHI nodes to communicate values between blocks. Therefore, the LLVM dialect has no operation directly equivalent to phi in LLVM IR. Instead, all terminators can pass values as successor operands as these values will be forwarded as block arguments when the control flow is transferred.

For example:

^bb1:
  %0 = llvm.addi %arg0, %cst : i32
  llvm.br ^bb2[%0: i32]

// If the control flow comes from ^bb1, %arg1 == %0.
^bb2(%arg1: i32)
  // ...

is equivalent to LLVM IR

%0:
  %1 = add i32 %arg0, %cst
  br %3

%3:
  %arg1 = phi [%1, %0], //...

Since there is no need to use the block identifier to differentiate the source of different values, the LLVM dialect supports terminators that transfer the control flow to the same block with different arguments. For example:

^bb1:
  llvm.cond_br %cond, ^bb2[%0: i32], ^bb2[%1: i32]

^bb2(%arg0: i32):
  // ...

Context-Level Values ¶

Some value kinds in LLVM IR, such as constants and undefs, are uniqued in context and used directly in relevant operations. MLIR does not support such values for thread-safety and concept parsimony reasons. Instead, regular values are produced by dedicated operations that have the corresponding semantics: llvm.mlir.constant, llvm.mlir.undef, llvm.mlir.poison, llvm.mlir.zero. Note how these operations are prefixed with mlir. to indicate that they don’t belong to LLVM IR but are only necessary to model it in MLIR. The values produced by these operations are usable just like any other value.

Examples:

// Create an undefined value of structure type with a 32-bit integer followed
// by a float.
%0 = llvm.mlir.undef : !llvm.struct<(i32, f32)>

// Null pointer.
%1 = llvm.mlir.zero : !llvm.ptr

// Create an zero initialized value of structure type with a 32-bit integer
// followed by a float.
%2 = llvm.mlir.zero :  !llvm.struct<(i32, f32)>

// Constant 42 as i32.
%3 = llvm.mlir.constant(42 : i32) : i32

// Splat dense vector constant.
%3 = llvm.mlir.constant(dense<1.0> : vector<4xf32>) : vector<4xf32>

Note that constants list the type twice. This is an artifact of the LLVM dialect not using built-in types, which are used for typed MLIR attributes. The syntax will be reevaluated after considering composite constants.

Globals ¶

Global variables are also defined using a special operation, llvm.mlir.global, located at the module level. Globals are MLIR symbols and are identified by their name.

Since functions need to be isolated-from-above, i.e. values defined outside the function cannot be directly used inside the function, an additional operation, llvm.mlir.addressof, is provided to locally define a value containing the address of a global. The actual value can then be loaded from that pointer, or a new value can be stored into it if the global is not declared constant. This is similar to LLVM IR where globals are accessed through name and have a pointer type.

Linkage ¶

Module-level named objects in the LLVM dialect, namely functions and globals, have an optional linkage attribute derived from LLVM IR linkage types. Linkage is specified by the same keyword as in LLVM IR and is located between the operation name (llvm.func or llvm.global) and the symbol name. If no linkage keyword is present, external linkage is assumed by default. Linkage is distinct from MLIR symbol visibility.

Attribute Pass-Through ¶

WARNING: this feature MUST NOT be used for any real workload. It is exclusively intended for quick prototyping. After that, attributes must be introduced as proper first-class concepts in the dialect.

The LLVM dialect provides a mechanism to forward function-level attributes to LLVM IR using the passthrough attribute. This is an array attribute containing either string attributes or array attributes. In the former case, the value of the string is interpreted as the name of LLVM IR function attribute. In the latter case, the array is expected to contain exactly two string attributes, the first corresponding to the name of LLVM IR function attribute, and the second corresponding to its value. Note that even integer LLVM IR function attributes have their value represented in the string form.

Example:

llvm.func @func() attributes {
  passthrough = ["readonly",           // value-less attribute
                 ["alignstack", "4"],  // integer attribute with value
                 ["other", "attr"]]    // attribute unknown to LLVM
} {
  llvm.return
}

If the attribute is not known to LLVM IR, it will be attached as a string attribute.

Types ¶

LLVM dialect uses built-in types whenever possible and defines a set of complementary types, which correspond to the LLVM IR types that cannot be directly represented with built-in types. Similarly to other MLIR context-owned objects, the creation and manipulation of LLVM dialect types is thread-safe.

MLIR does not support module-scoped named type declarations, e.g. %s = type {i32, i32} in LLVM IR. Instead, types must be fully specified at each use, except for recursive types where only the first reference to a named type needs to be fully specified. MLIR type aliases can be used to achieve more compact syntax.

The general syntax of LLVM dialect types is !llvm., followed by a type kind identifier (e.g., ptr for pointer or struct for structure) and by an optional list of type parameters in angle brackets. The dialect follows MLIR style for types with nested angle brackets and keyword specifiers rather than using different bracket styles to differentiate types. Types inside the angle brackets may omit the !llvm. prefix for brevity: the parser first attempts to find a type (starting with ! or a built-in type) and falls back to accepting a keyword. For example, !llvm.struct<(!llvm.ptr, f32)> and !llvm.struct<(ptr, f32)> are equivalent, with the latter being the canonical form, and denote a struct containing a pointer and a float.

Built-in Type Compatibility ¶

LLVM dialect accepts a subset of built-in types that are referred to as LLVM dialect-compatible types. The following types are compatible:

• Signless integers - iN (IntegerType).
• Floating point types - bfloat, half, float, double , f80, f128 (FloatType).
• 1D vectors of signless integers or floating point types - vector<NxT> (VectorType).

Note that only a subset of types that can be represented by a given class is compatible. For example, signed and unsigned integers are not compatible. LLVM provides a function, bool LLVM::isCompatibleType(Type), that can be used as a compatibility check.

Each LLVM IR type corresponds to exactly one MLIR type, either built-in or LLVM dialect type. For example, because i32 is LLVM-compatible, there is no !llvm.i32 type. However, !llvm.struct<(T, ...)> is defined in the LLVM dialect as there is no corresponding built-in type.

Additional Simple Types ¶

The following non-parametric types derived from the LLVM IR are available in the LLVM dialect:

• !llvm.ppc_fp128 (LLVMPPCFP128Type) - 128-bit floating-point value (two 64 bits).
• !llvm.token (LLVMTokenType) - a non-inspectable value associated with an operation.
• !llvm.metadata (LLVMMetadataType) - LLVM IR metadata, to be used only if the metadata cannot be represented as structured MLIR attributes.
• !llvm.void (LLVMVoidType) - does not represent any value; can only appear in function results.

These types represent a single value (or an absence thereof in case of void) and correspond to their LLVM IR counterparts.

Additional Parametric Types ¶

These types are parameterized by the types they contain, e.g., the pointee or the element type, which can be either compatible built-in or LLVM dialect types.

Pointer Types ¶

Pointer types specify an address in memory.

Pointers are opaque, i.e., do not indicate the type of the data pointed to, and are intended to simplify LLVM IR by encoding behavior relevant to the pointee type into operations rather than into types. Pointers can optionally be parametrized with an address space. The address space is an integer, but this choice may be reconsidered if MLIR implements named address spaces. The syntax of pointer types is as follows:

  llvm-ptr-type ::= `!llvm.ptr` (`<` integer-literal `>`)?

where the optional group containing the integer literal corresponds to the address space. All cases are represented by LLVMPointerType internally.

Array Types ¶

Array types represent sequences of elements in memory. Array elements can be addressed with a value unknown at compile time, and can be nested. Only 1D arrays are allowed though.

Array types are parameterized by the fixed size and the element type. Syntactically, their representation is the following:

  llvm-array-type ::= `!llvm.array<` integer-literal `x` type `>`

and they are internally represented as LLVMArrayType.

Function Types ¶

Function types represent the type of a function, i.e. its signature.

Function types are parameterized by the result type, the list of argument types and by an optional “variadic” flag. Unlike built-in FunctionType, LLVM dialect functions (LLVMFunctionType) always have single result, which may be !llvm.void if the function does not return anything. The syntax is as follows:

  llvm-func-type ::= `!llvm.func<` type `(` type-list (`,` `...`)? `)` `>`

For example,

!llvm.func<void ()>           // a function with no arguments;
!llvm.func<i32 (f32, i32)>    // a function with two arguments and a result;
!llvm.func<void (i32, ...)>   // a variadic function with at least one argument.

In the LLVM dialect, functions are not first-class objects and one cannot have a value of function type. Instead, one can take the address of a function and operate on pointers to functions.

Vector Types ¶

Vector types represent sequences of elements, typically when multiple data elements are processed by a single instruction (SIMD). Vectors are thought of as stored in registers and therefore vector elements can only be addressed through constant indices.

Vector types are parameterized by the size, which may be either fixed or a multiple of some fixed size in case of scalable vectors, and the element type. Vectors cannot be nested and only 1D vectors are supported. Scalable vectors are still considered 1D.

The LLVM dialect uses built-in vector type.

The following functions are provided to operate on any kind of the vector types compatible with the LLVM dialect:

• bool LLVM::isCompatibleVectorType(Type) - checks whether a type is a vector type compatible with the LLVM dialect;
• llvm::ElementCount LLVM::getVectorNumElements(Type) - returns the number of elements in any vector type compatible with the LLVM dialect;

Examples of Compatible Vector Types ¶

vector<42 x i32>                   // Vector of 42 32-bit integers.
vector<42 x !llvm.ptr>             // Vector of 42 pointers.
vector<[4] x i32>                  // Scalable vector of 32-bit integers with
                                   // size divisible by 4.
!llvm.array<2 x vector<2 x i32>>   // Array of 2 vectors of 2 32-bit integers.
!llvm.array<2 x vec<2 x ptr>> // Array of 2 vectors of 2 pointers.

Structure Types ¶

The structure type is used to represent a collection of data members together in memory. The elements of a structure may be any type that has a size.

Structure types are represented in a single dedicated class mlir::LLVM::LLVMStructType. Internally, the struct type stores a (potentially empty) name, a (potentially empty) list of contained types and a bitmask indicating whether the struct is named, opaque, packed or uninitialized. Structure types that don’t have a name are referred to as literal structs. Such structures are uniquely identified by their contents. Identified structs on the other hand are uniquely identified by the name.

Identified Structure Types ¶

Identified structure types are uniqued using their name in a given context. Attempting to construct an identified structure with the same name a structure that already exists in the context will result in the existing structure being returned. MLIR does not auto-rename identified structs in case of name conflicts because there is no naming scope equivalent to a module in LLVM IR since MLIR modules can be arbitrarily nested.

Programmatically, identified structures can be constructed in an uninitialized state. In this case, they are given a name but the body must be set up by a later call, using MLIR’s type mutation mechanism. Such uninitialized types can be used in type construction, but must be eventually initialized for IR to be valid. This mechanism allows for constructing recursive or mutually referring structure types: an uninitialized type can be used in its own initialization.

Once the type is initialized, its body cannot be changed anymore. Any further attempts to modify the body will fail and return failure to the caller unless the type is initialized with the exact same body. Type initialization is thread-safe; however, if a concurrent thread initializes the type before the current thread, the initialization may return failure.

The syntax for identified structure types is as follows.

llvm-ident-struct-type ::= `!llvm.struct<` string-literal, `opaque` `>`
                         | `!llvm.struct<` string-literal, `packed`?
                           `(` type-or-ref-list  `)` `>`
type-or-ref-list ::= <maybe empty comma-separated list of type-or-ref>
type-or-ref ::= <any compatible type with optional !llvm.>
              | `!llvm.`? `struct<` string-literal `>`

Literal Structure Types ¶

Literal structures are uniqued according to the list of elements they contain, and can optionally be packed. The syntax for such structs is as follows.

llvm-literal-struct-type ::= `!llvm.struct<` `packed`? `(` type-list `)` `>`
type-list ::= <maybe empty comma-separated list of types with optional !llvm.>

Literal structs cannot be recursive, but can contain other structs. Therefore, they must be constructed in a single step with the entire list of contained elements provided.

Examples of Structure Types ¶

!llvm.struct<>                  // NOT allowed
!llvm.struct<()>                // empty, literal
!llvm.struct<(i32)>             // literal
!llvm.struct<(struct<(i32)>)>   // struct containing a struct
!llvm.struct<packed (i8, i32)>  // packed struct
!llvm.struct<"a">               // recursive reference, only allowed within
                                // another struct, NOT allowed at top level
!llvm.struct<"a", ()>           // empty, named (necessary to differentiate from
                                // recursive reference)
!llvm.struct<"a", opaque>       // opaque, named
!llvm.struct<"a", (i32, ptr)>        // named
!llvm.struct<"a", packed (i8, i32)>  // named, packed

Unsupported Types ¶

LLVM IR label type does not have a counterpart in the LLVM dialect since, in MLIR, blocks are not values and don’t need a type.

Operations ¶

All operations in the LLVM IR dialect have a custom form in MLIR. The mnemonic of an operation is that used in LLVM IR prefixed with “llvm.”.

source

llvm.ashr (LLVM::AShrOp) ¶

Syntax:

operation ::= `llvm.ashr` (`exact` $isExact^)? $lhs `,` $rhs attr-dict `:` type($res)

Traits: AlwaysSpeculatableImplTrait, SameOperandsAndResultType

Interfaces: ConditionallySpeculatable, ExactFlagInterface, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes: ¶

Operands: ¶

Results: ¶

llvm.add (LLVM::AddOp) ¶

Syntax:

operation ::= `llvm.add` $lhs `,` $rhs ($overflowFlags^)? attr-dict `:` type($res)

Traits: AlwaysSpeculatableImplTrait, Commutative, SameOperandsAndResultType

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, IntegerOverflowFlagsInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands: ¶

Results: ¶

llvm.addrspacecast (LLVM::AddrSpaceCastOp) ¶

Syntax:

operation ::= `llvm.addrspacecast` $arg attr-dict `:` type($arg) `to` type($res)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface), PromotableOpInterface, ViewLikeOpInterface

Effects: MemoryEffects::Effect{}

Operands: ¶

Results: ¶

llvm.mlir.addressof (LLVM::AddressOfOp) ¶

Creates a pointer pointing to a global, alias or a function

Syntax:

operation ::= `llvm.mlir.addressof` $global_name attr-dict `:` qualified(type($res))

Creates an SSA value containing a pointer to a global value (function, variable or alias). The global value can be defined after its first referenced. If the global value is a constant, storing into it is not allowed.

Examples:

func @foo() {
  // Get the address of a global variable.
  %0 = llvm.mlir.addressof @const : !llvm.ptr

  // Use it as a regular pointer.
  %1 = llvm.load %0 : !llvm.ptr -> i32

  // Get the address of a function.
  %2 = llvm.mlir.addressof @foo : !llvm.ptr

  // The function address can be used for indirect calls.
  llvm.call %2() : !llvm.ptr, () -> ()

  // Get the address of an aliased global.
  %3 = llvm.mlir.addressof @const_alias : !llvm.ptr
}

// Define the global.
llvm.mlir.global @const(42 : i32) : i32

// Define an alias.
llvm.mlir.alias @const_alias : i32 {
  %0 = llvm.mlir.addressof @const : !llvm.ptr
  llvm.return %0 : !llvm.ptr
}

Traits: AlwaysSpeculatableImplTrait, ConstantLike

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface), SymbolUserOpInterface

Effects: MemoryEffects::Effect{}

Attributes: ¶

Results: ¶

llvm.mlir.alias (LLVM::AliasOp) ¶

LLVM dialect alias.

llvm.mlir.alias is a top level operation that defines a global alias for global variables and functions. The operation is always initialized by using a initializer region which could be a direct map to another global value or contain some address computation on top of it.

It uses a symbol for its value, which will be uniqued by the module with respect to other symbols in it.

Similarly to functions and globals, they can also have a linkage attribute. This attribute is placed between llvm.mlir.alias and the symbol name. If the attribute is omitted, external linkage is assumed by default.

Examples:

// Global alias use @-identifiers.
llvm.mlir.alias external @foo_alias {addr_space = 0 : i32} : !llvm.ptr {
  %0 = llvm.mlir.addressof @some_function : !llvm.ptr
  llvm.return %0 : !llvm.ptr
}

// More complex initialization.
llvm.mlir.alias linkonce_odr hidden @glob
{addr_space = 0 : i32, dso_local} : !llvm.array<32 x i32> {
  %0 = llvm.mlir.constant(1234 : i64) : i64
  %1 = llvm.mlir.addressof @glob.private : !llvm.ptr
  %2 = llvm.ptrtoint %1 : !llvm.ptr to i64
  %3 = llvm.add %2, %0 : i64
  %4 = llvm.inttoptr %3 : i64 to !llvm.ptr
  llvm.return %4 : !llvm.ptr
}

Traits: IsolatedFromAbove, SingleBlockImplicitTerminator<ReturnOp>, SingleBlock

Interfaces: Symbol

Attributes: ¶

llvm.alloca (LLVM::AllocaOp) ¶

Interfaces: DestructurableAllocationOpInterface, PromotableAllocationOpInterface

Attributes: ¶

Operands: ¶

Results: ¶

llvm.and (LLVM::AndOp) ¶

Syntax:

operation ::= `llvm.and` $lhs `,` $rhs attr-dict `:` type($res)

Traits: AlwaysSpeculatableImplTrait, SameOperandsAndResultType

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands: ¶

Results: ¶

llvm.cmpxchg (LLVM::AtomicCmpXchgOp) ¶

Syntax:

operation ::= `llvm.cmpxchg` (`weak` $weak^)? (`volatile` $volatile_^)? $ptr `,` $cmp `,` $val
              (`syncscope` `(` $syncscope^ `)`)? $success_ordering $failure_ordering
              attr-dict `:` qualified(type($ptr)) `,` type($val)

Interfaces: AccessGroupOpInterface, AliasAnalysisOpInterface, InferTypeOpInterface

Attributes: ¶

Operands: ¶

Results: ¶

llvm.atomicrmw (LLVM::AtomicRMWOp) ¶

Syntax:

operation ::= `llvm.atomicrmw` (`volatile` $volatile_^)? $bin_op $ptr `,` $val
              (`syncscope` `(` $syncscope^ `)`)? $ordering attr-dict `:`
              qualified(type($ptr)) `,` type($val)

Interfaces: AccessGroupOpInterface, AliasAnalysisOpInterface, InferTypeOpInterface

Attributes: ¶

Operands: ¶

Results: ¶

llvm.bitcast (LLVM::BitcastOp) ¶

Syntax:

operation ::= `llvm.bitcast` $arg attr-dict `:` type($arg) `to` type($res)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface), PromotableOpInterface

Effects: MemoryEffects::Effect{}

Operands: ¶

Results: ¶

llvm.blockaddress (LLVM::BlockAddressOp) ¶

Creates a LLVM blockaddress ptr

Syntax:

operation ::= `llvm.blockaddress` $block_addr
              attr-dict `:` qualified(type($res))

Creates an SSA value containing a pointer to a basic block. The block address information (function and block) is given by the BlockAddressAttr attribute. This operation assumes an existing llvm.blocktag operation identifying an existing MLIR block within a function. Example:

llvm.mlir.global private @g() : !llvm.ptr {
  %0 = llvm.blockaddress <function = @fn, tag = <id = 0>> : !llvm.ptr
  llvm.return %0 : !llvm.ptr
}

llvm.func @fn() {
  llvm.br ^bb1
^bb1:  // pred: ^bb0
  llvm.blocktag <id = 0>
  llvm.return
}

Traits: AlwaysSpeculatableImplTrait, ConstantLike

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface), SymbolUserOpInterface

Effects: MemoryEffects::Effect{}

Attributes: ¶

Describes a block address identified by a pair of `$function` and `$tag`.

Results: ¶

llvm.blocktag (LLVM::BlockTagOp) ¶

Syntax:

operation ::= `llvm.blocktag` $tag attr-dict

This operation uses a tag to uniquely identify an MLIR block in a function. The same tag is used by llvm.blockaddress in order to compute the target address.

A given function should have at most one llvm.blocktag operation with a given tag. This operation cannot be used as a terminator.

Example:

llvm.func @f() -> !llvm.ptr {
  %addr = llvm.blockaddress <function = @f, tag = <id = 1>> : !llvm.ptr
  llvm.br ^bb1
^bb1:
  llvm.blocktag <id = 1>
  llvm.return %addr : !llvm.ptr
}

Attributes: ¶

llvm.br (LLVM::BrOp) ¶

Syntax:

operation ::= `llvm.br` $dest (`(` $destOperands^ `:` type($destOperands) `)`)? attr-dict

Traits: AlwaysSpeculatableImplTrait, Terminator

Interfaces: BranchOpInterface, ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes: ¶

This attributes encapsulates "loop metadata". It is meant to decorate
branches that are "latches" (loop backedges) and maps to the `!llvm.loop`
metadatas: https://llvm.org/docs/LangRef.html#llvm-loop
It stores annotations in attribute parameters and groups related options in
nested attributes to provide structured access.

Operands: ¶

Successors: ¶

llvm.call_intrinsic (LLVM::CallIntrinsicOp) ¶

Call to an LLVM intrinsic function.

Call the specified llvm intrinsic. If the intrinsic is overloaded, use the MLIR function type of this op to determine which intrinsic to call.

Traits: AttrSizedOperandSegments

Interfaces: FastmathFlagsInterface

Attributes: ¶

Operands: ¶

Results: ¶

llvm.call (LLVM::CallOp) ¶

Call to an LLVM function.

In LLVM IR, functions may return either 0 or 1 value. LLVM IR dialect implements this behavior by providing a variadic call operation for 0- and 1-result functions. Even though MLIR supports multi-result functions, LLVM IR dialect disallows them.

The call instruction supports both direct and indirect calls. Direct calls start with a function name (@-prefixed) and indirect calls start with an SSA value (%-prefixed). The direct callee, if present, is stored as a function attribute callee. For indirect calls, the callee is of !llvm.ptr type and is stored as the first value in callee_operands. If and only if the callee is a variadic function, the var_callee_type attribute must carry the variadic LLVM function type. The trailing type list contains the optional indirect callee type and the MLIR function type, which differs from the LLVM function type that uses an explicit void type to model functions that do not return a value.

If this operatin has the no_inline attribute, then this specific function call will never be inlined. The opposite behavior will occur if the call has always_inline attribute. The inline_hint attribute indicates that it is desirable to inline this function call.

Examples:

// Direct call without arguments and with one result.
%0 = llvm.call @foo() : () -> (f32)

// Direct call with arguments and without a result.
llvm.call @bar(%0) : (f32) -> ()

// Indirect call with an argument and without a result.
%1 = llvm.mlir.addressof @foo : !llvm.ptr
llvm.call %1(%0) : !llvm.ptr, (f32) -> ()

// Direct variadic call.
llvm.call @printf(%0, %1) vararg(!llvm.func<i32 (ptr, ...)>) : (!llvm.ptr, i32) -> i32

// Indirect variadic call
llvm.call %1(%0) vararg(!llvm.func<void (...)>) : !llvm.ptr, (i32) -> ()

Traits: AttrSizedOperandSegments

Interfaces: AccessGroupOpInterface, AliasAnalysisOpInterface, BranchWeightOpInterface, CallOpInterface, FastmathFlagsInterface, SymbolUserOpInterface

Attributes: ¶

Operands: ¶

Results: ¶

llvm.comdat (LLVM::ComdatOp) ¶

LLVM dialect comdat region

Syntax:

operation ::= `llvm.comdat` $sym_name $body attr-dict

Provides access to object file COMDAT section/group functionality.

Examples:

llvm.comdat @__llvm_comdat {
  llvm.comdat_selector @any any
}
llvm.mlir.global internal constant @has_any_comdat(1 : i64) comdat(@__llvm_comdat::@any) : i64

Traits: NoRegionArguments, NoTerminator, SymbolTable

Interfaces: Symbol

Attributes: ¶

llvm.comdat_selector (LLVM::ComdatSelectorOp) ¶

LLVM dialect comdat selector declaration

Syntax:

operation ::= `llvm.comdat_selector` $sym_name $comdat attr-dict

Provides access to object file COMDAT section/group functionality.

Examples:

llvm.comdat @__llvm_comdat {
  llvm.comdat_selector @any any
}
llvm.mlir.global internal constant @has_any_comdat(1 : i64) comdat(@__llvm_comdat::@any) : i64

Interfaces: Symbol

Attributes: ¶

llvm.cond_br (LLVM::CondBrOp) ¶

Syntax:

operation ::= `llvm.cond_br` $condition ( `weights` `(` $branch_weights^ `)` )? `,`
              $trueDest (`(` $trueDestOperands^ `:` type($trueDestOperands) `)`)? `,`
              $falseDest (`(` $falseDestOperands^ `:` type($falseDestOperands) `)`)?
              attr-dict

Traits: AlwaysSpeculatableImplTrait, AttrSizedOperandSegments, Terminator

Interfaces: BranchOpInterface, BranchWeightOpInterface, ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes: ¶

This attributes encapsulates "loop metadata". It is meant to decorate
branches that are "latches" (loop backedges) and maps to the `!llvm.loop`
metadatas: https://llvm.org/docs/LangRef.html#llvm-loop
It stores annotations in attribute parameters and groups related options in
nested attributes to provide structured access.

Operands: ¶

Successors: ¶

llvm.mlir.constant (LLVM::ConstantOp) ¶

Defines a constant of LLVM type.

Syntax:

operation ::= `llvm.mlir.constant` `(` $value `)` attr-dict `:` type($res)

Unlike LLVM IR, MLIR does not have first-class constant values. Therefore, all constants must be created as SSA values before being used in other operations. llvm.mlir.constant creates such values for scalars, vectors, strings, structs, and array of structs. It has a mandatory value attribute whose type depends on the type of the constant value. The type of the constant value must correspond to the attribute type converted to LLVM IR type.

When creating constant scalars, the value attribute must be either an integer attribute or a floating point attribute. The type of the attribute may be omitted for i64 and f64 types that are implied.

When creating constant vectors, the value attribute must be either an array attribute, a dense attribute, or a sparse attribute that contains integers or floats. The number of elements in the result vector must match the number of elements in the attribute.

When creating constant strings, the value attribute must be a string attribute. The type of the constant must be an LLVM array of i8s, and the length of the array must match the length of the attribute.

When creating constant structs, the value attribute must be an array attribute that contains integers or floats. The type of the constant must be an LLVM struct type. The number of fields in the struct must match the number of elements in the attribute, and the type of each LLVM struct field must correspond to the type of the corresponding attribute element converted to LLVM IR.

When creating an array of structs, the value attribute must be an array attribute, itself containing zero, or undef, or array attributes for each potential nested array type, and the elements of the leaf array attributes for must match the struct element types or be zero or undef attributes.

Examples:

// Integer constant, internal i32 is mandatory
%0 = llvm.mlir.constant(42 : i32) : i32

// It's okay to omit i64.
%1 = llvm.mlir.constant(42) : i64

// Floating point constant.
%2 = llvm.mlir.constant(42.0 : f32) : f32

// Splat dense vector constant.
%3 = llvm.mlir.constant(dense<1.0> : vector<4xf32>) : vector<4xf32>

Traits: AlwaysSpeculatableImplTrait, ConstantLike

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes: ¶

Results: ¶

llvm.dso_local_equivalent (LLVM::DSOLocalEquivalentOp) ¶

Creates a LLVM dso_local_equivalent ptr

Syntax:

operation ::= `llvm.dso_local_equivalent` $function_name attr-dict `:` qualified(type($res))

Creates an SSA value containing a pointer to a global value (function or alias to function). It represents a function which is functionally equivalent to a given function, but is always defined in the current linkage unit. The target function may not have extern_weak linkage.

Examples:

llvm.mlir.global external constant @const() : i64 {
  %0 = llvm.mlir.addressof @const : !llvm.ptr
  %1 = llvm.ptrtoint %0 : !llvm.ptr to i64
  %2 = llvm.dso_local_equivalent @func : !llvm.ptr
  %4 = llvm.ptrtoint %2 : !llvm.ptr to i64
  llvm.return %4 : i64
}

Traits: AlwaysSpeculatableImplTrait, ConstantLike

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface), SymbolUserOpInterface

Effects: MemoryEffects::Effect{}

Attributes: ¶

Results: ¶

llvm.extractelement (LLVM::ExtractElementOp) ¶

Extract an element from an LLVM vector.

Syntax:

operation ::= `llvm.extractelement` $vector `[` $position `:` type($position) `]` attr-dict `:` type($vector)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands: ¶

Results: ¶

llvm.extractvalue (LLVM::ExtractValueOp) ¶

Extract a value from an LLVM struct.

Syntax:

operation ::= `llvm.extractvalue` $container `` $position attr-dict `:` type($container)
              custom<InsertExtractValueElementType>(type($res), ref(type($container)),
              ref($position))

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes: ¶

Operands: ¶

Results: ¶

llvm.fadd (LLVM::FAddOp) ¶

Syntax:

operation ::= `llvm.fadd` $lhs `,` $rhs attr-dict `:` type($res)

Traits: AlwaysSpeculatableImplTrait, SameOperandsAndResultType

Interfaces: ConditionallySpeculatable, FastmathFlagsInterface, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes: ¶

Operands: ¶

Results: ¶

llvm.fcmp (LLVM::FCmpOp) ¶

Traits: AlwaysSpeculatableImplTrait, SameTypeOperands

Interfaces: ConditionallySpeculatable, FastmathFlagsInterface, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes: ¶

Operands: ¶

Results: ¶

llvm.fdiv (LLVM::FDivOp) ¶

Syntax:

operation ::= `llvm.fdiv` $lhs `,` $rhs attr-dict `:` type($res)

Traits: AlwaysSpeculatableImplTrait, SameOperandsAndResultType

Interfaces: ConditionallySpeculatable, FastmathFlagsInterface, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes: ¶

Operands: ¶

Results: ¶

llvm.fmul (LLVM::FMulOp) ¶

Syntax:

operation ::= `llvm.fmul` $lhs `,` $rhs attr-dict `:` type($res)

Traits: AlwaysSpeculatableImplTrait, SameOperandsAndResultType

Interfaces: ConditionallySpeculatable, FastmathFlagsInterface, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes: ¶

Operands: ¶

Results: ¶

llvm.fneg (LLVM::FNegOp) ¶

Syntax:

operation ::= `llvm.fneg` $operand attr-dict `:` type($res)

Traits: AlwaysSpeculatableImplTrait, SameOperandsAndResultType

Interfaces: ConditionallySpeculatable, FastmathFlagsInterface, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes: ¶

Operands: ¶

Results: ¶

llvm.fpext (LLVM::FPExtOp) ¶

Syntax:

operation ::= `llvm.fpext` $arg attr-dict `:` type($arg) `to` type($res)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands: ¶

Results: ¶

llvm.fptosi (LLVM::FPToSIOp) ¶

Syntax:

operation ::= `llvm.fptosi` $arg attr-dict `:` type($arg) `to` type($res)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands: ¶

Results: ¶

llvm.fptoui (LLVM::FPToUIOp) ¶

Syntax:

operation ::= `llvm.fptoui` $arg attr-dict `:` type($arg) `to` type($res)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands: ¶

Results: ¶

llvm.fptrunc (LLVM::FPTruncOp) ¶

Syntax:

operation ::= `llvm.fptrunc` $arg attr-dict `:` type($arg) `to` type($res)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands: ¶

Results: ¶

llvm.frem (LLVM::FRemOp) ¶

Syntax:

operation ::= `llvm.frem` $lhs `,` $rhs attr-dict `:` type($res)

Traits: AlwaysSpeculatableImplTrait, SameOperandsAndResultType

Interfaces: ConditionallySpeculatable, FastmathFlagsInterface, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes: ¶

Operands: ¶

Results: ¶

llvm.fsub (LLVM::FSubOp) ¶

Syntax:

operation ::= `llvm.fsub` $lhs `,` $rhs attr-dict `:` type($res)

Traits: AlwaysSpeculatableImplTrait, SameOperandsAndResultType

Interfaces: ConditionallySpeculatable, FastmathFlagsInterface, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes: ¶

Operands: ¶

Results: ¶

llvm.fence (LLVM::FenceOp) ¶

Syntax:

operation ::= `llvm.fence` (`syncscope` `(` $syncscope^ `)`)? $ordering attr-dict

Attributes: ¶

llvm.freeze (LLVM::FreezeOp) ¶

Syntax:

operation ::= `llvm.freeze` $val attr-dict `:` type($val)

Traits: AlwaysSpeculatableImplTrait, SameOperandsAndResultType

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands: ¶

Results: ¶

llvm.getelementptr (LLVM::GEPOp) ¶

Syntax:

operation ::= `llvm.getelementptr` ($noWrapFlags^)?
              $base `[` custom<GEPIndices>($dynamicIndices, $rawConstantIndices) `]` attr-dict
              `:` functional-type(operands, results) `,` $elem_type

This operation mirrors LLVM IRs ‘getelementptr’ operation that is used to perform pointer arithmetic.

Like in LLVM IR, it is possible to use both constants as well as SSA values as indices. In the case of indexing within a structure, it is required to either use constant indices directly, or supply a constant SSA value.

The no-wrap flags can be used to specify the low-level pointer arithmetic overflow behavior that LLVM uses after lowering the operation to LLVM IR. Valid options include ‘inbounds’ (pointer arithmetic must be within object bounds), ’nusw’ (no unsigned signed wrap), and ’nuw’ (no unsigned wrap). Note that ‘inbounds’ implies ’nusw’ which is ensured by the enum definition. The flags can be set individually or in combination.

Examples:

// GEP with an SSA value offset
%0 = llvm.getelementptr %1[%2] : (!llvm.ptr, i64) -> !llvm.ptr, f32

// GEP with a constant offset and the inbounds attribute set
%0 = llvm.getelementptr inbounds %1[3] : (!llvm.ptr) -> !llvm.ptr, f32

// GEP with constant offsets into a structure
%0 = llvm.getelementptr %1[0, 1]
   : (!llvm.ptr) -> !llvm.ptr, !llvm.struct<(i32, f32)>

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, DestructurableAccessorOpInterface, NoMemoryEffect (MemoryEffectOpInterface), PromotableOpInterface, SafeMemorySlotAccessOpInterface, ViewLikeOpInterface

Effects: MemoryEffects::Effect{}

Attributes: ¶

Operands: ¶

Results: ¶

llvm.mlir.global_ctors (LLVM::GlobalCtorsOp) ¶

LLVM dialect global_ctors.

Syntax:

operation ::= `llvm.mlir.global_ctors` `ctors` `=` $ctors
              `,` `priorities` `=` $priorities
              `,` `data` `=` $data
              attr-dict

Specifies a list of constructor functions, priorities, and associated data. The functions referenced by this array will be called in ascending order of priority (i.e. lowest first) when the module is loaded. The order of functions with the same priority is not defined. This operation is translated to LLVM’s global_ctors global variable. The initializer functions are run at load time. However, if the associated data is not #llvm.zero, functions only run if the data is not discarded.

Examples:

llvm.func @ctor() {
  ...
  llvm.return
}
llvm.mlir.global_ctors ctors = [@ctor], priorities = [0],
                               data = [#llvm.zero]

Interfaces: SymbolUserOpInterface

Attributes: ¶

llvm.mlir.global_dtors (LLVM::GlobalDtorsOp) ¶

LLVM dialect global_dtors.

Syntax:

operation ::= `llvm.mlir.global_dtors` `dtors` `=` $dtors
              `,` `priorities` `=` $priorities
              `,` `data` `=` $data
              attr-dict

Specifies a list of destructor functions and priorities. The functions referenced by this array will be called in descending order of priority (i.e. highest first) when the module is unloaded. The order of functions with the same priority is not defined. This operation is translated to LLVM’s global_dtors global variable. The destruction functions are run at load time. However, if the associated data is not #llvm.zero, functions only run if the data is not discarded.

Examples:

llvm.func @dtor() {
  llvm.return
}
llvm.mlir.global_dtors dtors = [@dtor], priorities = [0],
                               data = [#llvm.zero]

Interfaces: SymbolUserOpInterface

Attributes: ¶

llvm.mlir.global (LLVM::GlobalOp) ¶

LLVM dialect global.

Since MLIR allows for arbitrary operations to be present at the top level, global variables are defined using the llvm.mlir.global operation. Both global constants and variables can be defined, and the value may also be initialized in both cases.

There are two forms of initialization syntax. Simple constants that can be represented as MLIR attributes can be given in-line:

llvm.mlir.global @variable(32.0 : f32) : f32

This initialization and type syntax is similar to llvm.mlir.constant and may use two types: one for MLIR attribute and another for the LLVM value. These types must be compatible.

More complex constants that cannot be represented as MLIR attributes can be given in an initializer region:

// This global is initialized with the equivalent of:
//   i32* getelementptr (i32* @g2, i32 2)
llvm.mlir.global constant @int_gep() : !llvm.ptr {
  %0 = llvm.mlir.addressof @g2 : !llvm.ptr
  %1 = llvm.mlir.constant(2 : i32) : i32
  %2 = llvm.getelementptr %0[%1]
     : (!llvm.ptr, i32) -> !llvm.ptr, i32
  // The initializer region must end with `llvm.return`.
  llvm.return %2 : !llvm.ptr
}

Only one of the initializer attribute or initializer region may be provided.

llvm.mlir.global must appear at top-level of the enclosing module. It uses an @-identifier for its value, which will be uniqued by the module with respect to other @-identifiers in it.

Examples:

// Global values use @-identifiers.
llvm.mlir.global constant @cst(42 : i32) : i32

// Non-constant values must also be initialized.
llvm.mlir.global @variable(32.0 : f32) : f32

// Strings are expected to be of wrapped LLVM i8 array type and do not
// automatically include the trailing zero.
llvm.mlir.global @string("abc") : !llvm.array<3 x i8>

// For strings globals, the trailing type may be omitted.
llvm.mlir.global constant @no_trailing_type("foo bar")

// A complex initializer is constructed with an initializer region.
llvm.mlir.global constant @int_gep() : !llvm.ptr {
  %0 = llvm.mlir.addressof @g2 : !llvm.ptr
  %1 = llvm.mlir.constant(2 : i32) : i32
  %2 = llvm.getelementptr %0[%1]
     : (!llvm.ptr, i32) -> !llvm.ptr, i32
  llvm.return %2 : !llvm.ptr
}

Similarly to functions, globals have a linkage attribute. In the custom syntax, this attribute is placed between llvm.mlir.global and the optional constant keyword. If the attribute is omitted, external linkage is assumed by default.

Examples:

// A constant with internal linkage will not participate in linking.
llvm.mlir.global internal constant @cst(42 : i32) : i32

// By default, "external" linkage is assumed and the global participates in
// symbol resolution at link-time.
llvm.mlir.global @glob(0 : f32) : f32

// Alignment is optional
llvm.mlir.global private constant @y(dense<1.0> : tensor<8xf32>) : !llvm.array<8 x f32>

Like global variables in LLVM IR, globals can have an (optional) alignment attribute using keyword alignment. The integer value of the alignment must be a positive integer that is a power of 2.

Examples:

// Alignment is optional
llvm.mlir.global private constant @y(dense<1.0> : tensor<8xf32>) { alignment = 32 : i64 } : !llvm.array<8 x f32>

Traits: IsolatedFromAbove, SingleBlockImplicitTerminator<ReturnOp>, SingleBlock

Interfaces: Symbol

Attributes: ¶

llvm.icmp (LLVM::ICmpOp) ¶

Traits: AlwaysSpeculatableImplTrait, SameTypeOperands

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes: ¶

Operands: ¶

Results: ¶

llvm.indirectbr (LLVM::IndirectBrOp) ¶

Syntax:

operation ::= `llvm.indirectbr` $addr `:` type($addr) `,`
              custom<IndirectBrOpSucessors>(ref(type($addr)),
              $successors,
              $succOperands,
              type($succOperands))
              attr-dict

Transfer control flow to address in $addr. A list of possible target blocks in $successors can be provided and maybe used as a hint in LLVM:

...
llvm.func @g(...
  %dest = llvm.blockaddress <function = @g, tag = <id = 0>> : !llvm.ptr
  llvm.indirectbr %dest : !llvm.ptr, [
    ^head
  ]
^head:
  llvm.blocktag <id = 0>
  llvm.return %arg0 : i32
  ...

It also supports a list of operands that can be passed to a target block:

  llvm.indirectbr %dest : !llvm.ptr, [
    ^head(%arg0 : i32),
    ^tail(%arg1, %arg0 : i32, i32)
  ]
^head(%r0 : i32):
  llvm.return %r0 : i32
^tail(%r1 : i32, %r2 : i32):
  ...

Traits: AlwaysSpeculatableImplTrait, SameVariadicOperandSize, Terminator

Interfaces: BranchOpInterface, ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes: ¶

Operands: ¶

Successors: ¶

llvm.inline_asm (LLVM::InlineAsmOp) ¶

Syntax:

operation ::= `llvm.inline_asm` (`has_side_effects` $has_side_effects^)?
              (`is_align_stack` $is_align_stack^)?
              (`asm_dialect` `=` $asm_dialect^)?
              (`operand_attrs` `=` $operand_attrs^)?
              attr-dict
              $asm_string `,` $constraints
              operands `:` functional-type(operands, results)

The InlineAsmOp mirrors the underlying LLVM semantics with a notable exception: the embedded asm_string is not allowed to define or reference any symbol or any global variable: only the operands of the op may be read, written, or referenced. Attempting to define or reference any symbol or any global behavior is considered undefined behavior at this time.

Interfaces: MemoryEffectOpInterface

Attributes: ¶

Operands: ¶

Results: ¶

llvm.insertelement (LLVM::InsertElementOp) ¶

Insert an element into an LLVM vector.

Syntax:

operation ::= `llvm.insertelement` $value `,` $vector `[` $position `:` type($position) `]` attr-dict `:`
              type($vector)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands: ¶

Results: ¶

llvm.insertvalue (LLVM::InsertValueOp) ¶

Insert a value into an LLVM struct.

Syntax:

operation ::= `llvm.insertvalue` $value `,` $container `` $position attr-dict `:` type($container)
              custom<InsertExtractValueElementType>(type($value), ref(type($container)),
              ref($position))

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes: ¶

Operands: ¶

Results: ¶

llvm.inttoptr (LLVM::IntToPtrOp) ¶

Syntax:

operation ::= `llvm.inttoptr` $arg (`dereferenceable` `` $dereferenceable^)? attr-dict `:` type($arg) `to` type($res)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, DereferenceableOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes: ¶

Defines `dereferenceable` or `dereferenceable_or_null` metadata that can
be set via the `DereferenceableOpInterface` on an `inttoptr` operation or
on a `load` operation which loads a pointer. The attribute is used to
denote that the result of these operations is dereferenceable up to a
certain number of bytes, represented by `$bytes`. The optional `$mayBeNull`
parameter is set to true if the attribute defines `dereferenceable_or_null`
metadata.
See the following links for more details:

https://llvm.org/docs/LangRef.html#dereferenceable-metadata

https://llvm.org/docs/LangRef.html#dereferenceable-or-null-metadata

Operands: ¶

Results: ¶

llvm.invoke (LLVM::InvokeOp) ¶

Traits: AttrSizedOperandSegments, Terminator

Interfaces: BranchOpInterface, BranchWeightOpInterface, CallOpInterface

Attributes: ¶

Operands: ¶

Results: ¶

Successors: ¶

llvm.func (LLVM::LLVMFuncOp) ¶

LLVM dialect function.

MLIR functions are defined by an operation that is not built into the IR itself. The LLVM dialect provides an llvm.func operation to define functions compatible with LLVM IR. These functions have LLVM dialect function type but use MLIR syntax to express it. They are required to have exactly one result type. LLVM function operation is intended to capture additional properties of LLVM functions, such as linkage and calling convention, that may be modeled differently by the built-in MLIR function.

// The type of @bar is !llvm<"i64 (i64)">
llvm.func @bar(%arg0: i64) -> i64 {
  llvm.return %arg0 : i64
}

// Type type of @foo is !llvm<"void (i64)">
// !llvm.void type is omitted
llvm.func @foo(%arg0: i64) {
  llvm.return
}

// A function with `internal` linkage.
llvm.func internal @internal_func() {
  llvm.return
}

Traits: AutomaticAllocationScope, IsolatedFromAbove

Interfaces: CallableOpInterface, FunctionOpInterface, Symbol

Attributes: ¶

Represents the LLVM target features as a list that can be checked within
passes/rewrites.
Example:
#llvm.target_features<["+sme", "+sve", "+sme-f64f64"]>
Then within a pass or rewrite the features active at an op can be queried:
auto targetFeatures = LLVM::TargetFeaturesAttr::featuresAt(op);

if (!targetFeatures.contains("+sme-f64f64"))
  return failure();

A hint to the compiler that indicates most operations used in the function
are explictly vectorized using a particular vector type. `$hint` is the
vector or scalar type in particular. `$is_signed` can be used with integer
types to state whether the type is signed.

llvm.lshr (LLVM::LShrOp) ¶

Syntax:

operation ::= `llvm.lshr` (`exact` $isExact^)? $lhs `,` $rhs attr-dict `:` type($res)

Traits: AlwaysSpeculatableImplTrait, SameOperandsAndResultType

Interfaces: ConditionallySpeculatable, ExactFlagInterface, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes: ¶

Operands: ¶

Results: ¶

llvm.landingpad (LLVM::LandingpadOp) ¶

Attributes: ¶

Operands: ¶

Results: ¶

llvm.linker_options (LLVM::LinkerOptionsOp) ¶

Options to pass to the linker when the object file is linked

Syntax:

operation ::= `llvm.linker_options` $options attr-dict

Pass the given options to the linker when the resulting object file is linked. This is used extensively on Windows to determine the C runtime that the object files should link against.

Examples:

// Link against the MSVC static threaded CRT.
llvm.linker_options ["/DEFAULTLIB:", "libcmt"]

// Link against aarch64 compiler-rt builtins
llvm.linker_options ["-l", "clang_rt.builtins-aarch64"]

Attributes: ¶

llvm.load (LLVM::LoadOp) ¶

Syntax:

operation ::= `llvm.load` (`volatile` $volatile_^)? $addr
              (`atomic` (`syncscope` `(` $syncscope^ `)`)? $ordering^)?
              (`invariant` $invariant^)?
              (`invariant_group` $invariantGroup^)?
              (`dereferenceable` `` $dereferenceable^)?
              attr-dict `:` qualified(type($addr)) `->` type($res)

The load operation is used to read from memory. A load may be marked as atomic, volatile, and/or nontemporal, and takes a number of optional attributes that specify aliasing information.

An atomic load only supports a limited set of pointer, integer, and floating point types, and requires an explicit alignment.

Examples:

// A volatile load of a float variable.
%0 = llvm.load volatile %ptr : !llvm.ptr -> f32

// A nontemporal load of a float variable.
%0 = llvm.load %ptr {nontemporal} : !llvm.ptr -> f32

// An atomic load of an integer variable.
%0 = llvm.load %ptr atomic monotonic {alignment = 8 : i64}
    : !llvm.ptr -> i64

See the following link for more details: https://llvm.org/docs/LangRef.html#load-instruction

Interfaces: AccessGroupOpInterface, AliasAnalysisOpInterface, DereferenceableOpInterface, DestructurableAccessorOpInterface, MemoryEffectOpInterface, PromotableMemOpInterface, SafeMemorySlotAccessOpInterface

Attributes: ¶

Defines `dereferenceable` or `dereferenceable_or_null` metadata that can
be set via the `DereferenceableOpInterface` on an `inttoptr` operation or
on a `load` operation which loads a pointer. The attribute is used to
denote that the result of these operations is dereferenceable up to a
certain number of bytes, represented by `$bytes`. The optional `$mayBeNull`
parameter is set to true if the attribute defines `dereferenceable_or_null`
metadata.
See the following links for more details:

https://llvm.org/docs/LangRef.html#dereferenceable-metadata

https://llvm.org/docs/LangRef.html#dereferenceable-or-null-metadata

Operands: ¶

Results: ¶

llvm.module_flags (LLVM::ModuleFlagsOp) ¶

Information about module properties

Syntax:

operation ::= `llvm.module_flags` $flags attr-dict

Represents the equivalent in MLIR for LLVM’s llvm.module.flags metadata, which requires a list of metadata triplets. Each triplet entry is described by a ModuleFlagAttr.

Example:

llvm.module.flags [
  #llvm.mlir.module_flag<error, "wchar_size", 4>,
  #llvm.mlir.module_flag<max, "PIC Level", 2>
]

Attributes: ¶

llvm.mul (LLVM::MulOp) ¶

Syntax:

operation ::= `llvm.mul` $lhs `,` $rhs ($overflowFlags^)? attr-dict `:` type($res)

Traits: AlwaysSpeculatableImplTrait, Commutative, SameOperandsAndResultType

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, IntegerOverflowFlagsInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands: ¶

Results: ¶

llvm.mlir.none (LLVM::NoneTokenOp) ¶

Defines a value containing an empty token to LLVM type.

Syntax:

operation ::= `llvm.mlir.none` attr-dict `:` type($res)

Unlike LLVM IR, MLIR does not have first-class token values. They must be explicitly created as SSA values using llvm.mlir.none. This operation has no operands or attributes, and returns a none token value of a wrapped LLVM IR pointer type.

Examples:

%0 = llvm.mlir.none : !llvm.token

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Results: ¶

llvm.or (LLVM::OrOp) ¶

Syntax:

operation ::= `llvm.or` (`disjoint` $isDisjoint^)? $lhs `,` $rhs attr-dict `:` type($res)

Traits: AlwaysSpeculatableImplTrait, SameOperandsAndResultType

Interfaces: ConditionallySpeculatable, DisjointFlagInterface, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes: ¶

Operands: ¶

Results: ¶

llvm.mlir.poison (LLVM::PoisonOp) ¶

Creates a poison value of LLVM dialect type.

Syntax:

operation ::= `llvm.mlir.poison` attr-dict `:` type($res)

Unlike LLVM IR, MLIR does not have first-class poison values. Such values must be created as SSA values using llvm.mlir.poison. This operation has no operands or attributes. It creates a poison value of the specified LLVM IR dialect type.

Example:

// Create a poison value for a structure with a 32-bit integer followed
// by a float.
%0 = llvm.mlir.poison : !llvm.struct<(i32, f32)>

Traits: AlwaysSpeculatableImplTrait, ConstantLike

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Results: ¶

llvm.ptrtoint (LLVM::PtrToIntOp) ¶

Syntax:

operation ::= `llvm.ptrtoint` $arg attr-dict `:` type($arg) `to` type($res)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands: ¶

Results: ¶

llvm.resume (LLVM::ResumeOp) ¶

Syntax:

operation ::= `llvm.resume` $value attr-dict `:` type($value)

Traits: Terminator

Operands: ¶

llvm.return (LLVM::ReturnOp) ¶

Syntax:

operation ::= `llvm.return` attr-dict ($arg^ `:` type($arg))?

Traits: AlwaysSpeculatableImplTrait, ReturnLike, Terminator

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface), RegionBranchTerminatorOpInterface

Effects: MemoryEffects::Effect{}

Operands: ¶

llvm.sdiv (LLVM::SDivOp) ¶

Syntax:

operation ::= `llvm.sdiv` (`exact` $isExact^)? $lhs `,` $rhs attr-dict `:` type($res)

Traits: AlwaysSpeculatableImplTrait, SameOperandsAndResultType

Interfaces: ConditionallySpeculatable, ExactFlagInterface, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes: ¶

Operands: ¶

Results: ¶

llvm.sext (LLVM::SExtOp) ¶

Syntax:

operation ::= `llvm.sext` $arg attr-dict `:` type($arg) `to` type($res)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands: ¶

Results: ¶

llvm.sitofp (LLVM::SIToFPOp) ¶

Syntax:

operation ::= `llvm.sitofp` $arg attr-dict `:` type($arg) `to` type($res)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands: ¶

Results: ¶

llvm.srem (LLVM::SRemOp) ¶

Syntax:

operation ::= `llvm.srem` $lhs `,` $rhs attr-dict `:` type($res)

Traits: AlwaysSpeculatableImplTrait, SameOperandsAndResultType

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands: ¶

Results: ¶

llvm.select (LLVM::SelectOp) ¶

Syntax:

operation ::= `llvm.select` operands attr-dict `:` type($condition) `,` type($res)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, FastmathFlagsInterface, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface), SelectLikeOpInterface

Effects: MemoryEffects::Effect{}

Attributes: ¶

Operands: ¶

Results: ¶

llvm.shl (LLVM::ShlOp) ¶

Syntax:

operation ::= `llvm.shl` $lhs `,` $rhs ($overflowFlags^)? attr-dict `:` type($res)

Traits: AlwaysSpeculatableImplTrait, SameOperandsAndResultType

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, IntegerOverflowFlagsInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands: ¶

Results: ¶

llvm.shufflevector (LLVM::ShuffleVectorOp) ¶

Construct a permutation of two vectors.

Syntax:

operation ::= `llvm.shufflevector` $v1 `,` $v2 $mask attr-dict `:` type($v1)
              custom<ShuffleType>(ref(type($v1)), type($res), ref($mask))

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes: ¶

Operands: ¶

Results: ¶

llvm.store (LLVM::StoreOp) ¶

Syntax:

operation ::= `llvm.store` (`volatile` $volatile_^)? $value `,` $addr
              (`atomic` (`syncscope` `(` $syncscope^ `)`)? $ordering^)?
              (`invariant_group` $invariantGroup^)?
              attr-dict `:` type($value) `,` qualified(type($addr))

The store operation is used to write to memory. A store may be marked as atomic, volatile, and/or nontemporal, and takes a number of optional attributes that specify aliasing information.

An atomic store only supports a limited set of pointer, integer, and floating point types, and requires an explicit alignment.

Examples:

// A volatile store of a float variable.
llvm.store volatile %val, %ptr : f32, !llvm.ptr

// A nontemporal store of a float variable.
llvm.store %val, %ptr {nontemporal} : f32, !llvm.ptr

// An atomic store of an integer variable.
llvm.store %val, %ptr atomic monotonic {alignment = 8 : i64}
    : i64, !llvm.ptr

See the following link for more details: https://llvm.org/docs/LangRef.html#store-instruction

Interfaces: AccessGroupOpInterface, AliasAnalysisOpInterface, DestructurableAccessorOpInterface, MemoryEffectOpInterface, PromotableMemOpInterface, SafeMemorySlotAccessOpInterface

Attributes: ¶

Operands: ¶

llvm.sub (LLVM::SubOp) ¶

Syntax:

operation ::= `llvm.sub` $lhs `,` $rhs ($overflowFlags^)? attr-dict `:` type($res)

Traits: AlwaysSpeculatableImplTrait, SameOperandsAndResultType

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, IntegerOverflowFlagsInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands: ¶

Results: ¶

llvm.switch (LLVM::SwitchOp) ¶

Syntax:

operation ::= `llvm.switch` $value `:` type($value) `,`
              $defaultDestination (`(` $defaultOperands^ `:` type($defaultOperands) `)`)?
              custom<SwitchOpCases>(ref(type($value)), $case_values, $caseDestinations,
              $caseOperands, type($caseOperands))
              attr-dict

Traits: AlwaysSpeculatableImplTrait, AttrSizedOperandSegments, Terminator

Interfaces: BranchOpInterface, BranchWeightOpInterface, ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes: ¶

Operands: ¶

Successors: ¶

llvm.trunc (LLVM::TruncOp) ¶

Syntax:

operation ::= `llvm.trunc` $arg ($overflowFlags^)? attr-dict `:` type($arg) `to` type($res)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, IntegerOverflowFlagsInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands: ¶

Results: ¶

llvm.udiv (LLVM::UDivOp) ¶

Syntax:

operation ::= `llvm.udiv` (`exact` $isExact^)? $lhs `,` $rhs attr-dict `:` type($res)

Traits: AlwaysSpeculatableImplTrait, SameOperandsAndResultType

Interfaces: ConditionallySpeculatable, ExactFlagInterface, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes: ¶

Operands: ¶

Results: ¶

llvm.uitofp (LLVM::UIToFPOp) ¶

Syntax:

operation ::= `llvm.uitofp` (`nneg` $nonNeg^)? $arg attr-dict `:` type($arg) `to` type($res)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface), NonNegFlagInterface

Effects: MemoryEffects::Effect{}

Attributes: ¶

Operands: ¶

Results: ¶

llvm.urem (LLVM::URemOp) ¶

Syntax:

operation ::= `llvm.urem` $lhs `,` $rhs attr-dict `:` type($res)

Traits: AlwaysSpeculatableImplTrait, SameOperandsAndResultType

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands: ¶

Results: ¶

llvm.mlir.undef (LLVM::UndefOp) ¶

Creates an undefined value of LLVM dialect type.

Syntax:

operation ::= `llvm.mlir.undef` attr-dict `:` type($res)

Unlike LLVM IR, MLIR does not have first-class undefined values. Such values must be created as SSA values using llvm.mlir.undef. This operation has no operands or attributes. It creates an undefined value of the specified LLVM IR dialect type.

Example:

// Create a structure with a 32-bit integer followed by a float.
%0 = llvm.mlir.undef : !llvm.struct<(i32, f32)>

Traits: AlwaysSpeculatableImplTrait, ConstantLike

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Results: ¶

llvm.unreachable (LLVM::UnreachableOp) ¶

Syntax:

operation ::= `llvm.unreachable` attr-dict

Traits: Terminator

llvm.va_arg (LLVM::VaArgOp) ¶

Syntax:

operation ::= `llvm.va_arg` $arg attr-dict `:` functional-type($arg, $res)

Operands: ¶

Results: ¶

llvm.xor (LLVM::XOrOp) ¶

Syntax:

operation ::= `llvm.xor` $lhs `,` $rhs attr-dict `:` type($res)

Traits: AlwaysSpeculatableImplTrait, SameOperandsAndResultType

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands: ¶

Results: ¶

llvm.zext (LLVM::ZExtOp) ¶

Syntax:

operation ::= `llvm.zext` (`nneg` $nonNeg^)? $arg attr-dict `:` type($arg) `to` type($res)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface), NonNegFlagInterface

Effects: MemoryEffects::Effect{}

Attributes: ¶

Operands: ¶

Results: ¶

llvm.mlir.zero (LLVM::ZeroOp) ¶

Creates a zero-initialized value of LLVM dialect type.

Syntax:

operation ::= `llvm.mlir.zero` attr-dict `:` type($res)

Unlike LLVM IR, MLIR does not have first-class zero-initialized values. Such values must be created as SSA values using llvm.mlir.zero. This operation has no operands or attributes. It creates a zero-initialized value of the specified LLVM IR dialect type.

Example:

// Create a zero-initialized value for a structure with a 32-bit integer
// followed by a float.
%0 = llvm.mlir.zero : !llvm.struct<(i32, f32)>

Traits: AlwaysSpeculatableImplTrait, ConstantLike

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Results: ¶

Operations for LLVM IR Intrinsics ¶

MLIR operation system is open making it unnecessary to introduce a hard bound between “core” operations and “intrinsics”. General LLVM IR intrinsics are modeled as first-class operations in the LLVM dialect. Target-specific LLVM IR intrinsics, e.g., NVVM or ROCDL, are modeled as separate dialects.

source

llvm.intr.acos (LLVM::ACosOp) ¶

Syntax:

operation ::= `llvm.intr.acos` `(` operands `)` attr-dict `:` functional-type(operands, results)

Traits: AlwaysSpeculatableImplTrait, SameOperandsAndResultType

Interfaces: ConditionallySpeculatable, FastmathFlagsInterface, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes: ¶

Operands: ¶

Results: ¶

llvm.intr.asin (LLVM::ASinOp) ¶

Syntax:

operation ::= `llvm.intr.asin` `(` operands `)` attr-dict `:` functional-type(operands, results)

Traits: AlwaysSpeculatableImplTrait, SameOperandsAndResultType

Interfaces: ConditionallySpeculatable, FastmathFlagsInterface, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes: ¶

Operands: ¶

Results: ¶

llvm.intr.atan2 (LLVM::ATan2Op) ¶

Syntax:

operation ::= `llvm.intr.atan2` `(` operands `)` attr-dict `:` functional-type(operands, results)

Traits: AlwaysSpeculatableImplTrait, SameOperandsAndResultType

Interfaces: ConditionallySpeculatable, FastmathFlagsInterface, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes: ¶

Operands: ¶

Results: ¶

llvm.intr.atan (LLVM::ATanOp) ¶

Syntax:

operation ::= `llvm.intr.atan` `(` operands `)` attr-dict `:` functional-type(operands, results)

Traits: AlwaysSpeculatableImplTrait, SameOperandsAndResultType

Interfaces: ConditionallySpeculatable, FastmathFlagsInterface, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes: ¶

Operands: ¶

Results: ¶

llvm.intr.abs (LLVM::AbsOp) ¶

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes: ¶

Operands: ¶

Results: ¶

llvm.intr.annotation (LLVM::Annotation) ¶

Interfaces: InferTypeOpInterface

Operands: ¶

Results: ¶

llvm.intr.assume (LLVM::AssumeOp) ¶

Syntax:

operation ::= `llvm.intr.assume` $cond
              ( custom<OpBundles>($op_bundle_operands, type($op_bundle_operands),
              $op_bundle_tags)^ )?
              `:` type($cond) attr-dict

Attributes: ¶

Operands: ¶

llvm.intr.bitreverse (LLVM::BitReverseOp) ¶

Syntax:

operation ::= `llvm.intr.bitreverse` `(` operands `)` attr-dict `:` functional-type(operands, results)

Traits: AlwaysSpeculatableImplTrait, SameOperandsAndResultType

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands: ¶

Results: ¶

llvm.intr.bswap (LLVM::ByteSwapOp) ¶

Syntax:

operation ::= `llvm.intr.bswap` `(` operands `)` attr-dict `:` functional-type(operands, results)

Traits: AlwaysSpeculatableImplTrait, SameOperandsAndResultType

Interfaces: ConditionallySpeculatable, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Operands: ¶

Results: ¶

llvm.intr.experimental.constrained.fpext (LLVM::ConstrainedFPExtIntr) ¶

Syntax:

operation ::= `llvm.intr.experimental.constrained.fpext` $arg_0 $fpExceptionBehavior attr-dict `:` type($arg_0) `to` type(results)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, FPExceptionBehaviorOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes: ¶

Operands: ¶

Results: ¶

llvm.intr.experimental.constrained.fptrunc (LLVM::ConstrainedFPTruncIntr) ¶

Syntax:

operation ::= `llvm.intr.experimental.constrained.fptrunc` $arg_0 $roundingmode $fpExceptionBehavior attr-dict `:` type($arg_0) `to` type(results)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, FPExceptionBehaviorOpInterface, NoMemoryEffect (MemoryEffectOpInterface), RoundingModeOpInterface

Effects: MemoryEffects::Effect{}

Attributes: ¶

Operands: ¶

Results: ¶

llvm.intr.experimental.constrained.sitofp (LLVM::ConstrainedSIToFP) ¶

Syntax:

operation ::= `llvm.intr.experimental.constrained.sitofp` $arg_0 $roundingmode $fpExceptionBehavior attr-dict `:` type($arg_0) `to` type(results)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, FPExceptionBehaviorOpInterface, NoMemoryEffect (MemoryEffectOpInterface), RoundingModeOpInterface

Effects: MemoryEffects::Effect{}

Attributes: ¶

Operands: ¶

Results: ¶

llvm.intr.experimental.constrained.uitofp (LLVM::ConstrainedUIToFP) ¶

Syntax:

operation ::= `llvm.intr.experimental.constrained.uitofp` $arg_0 $roundingmode $fpExceptionBehavior attr-dict `:` type($arg_0) `to` type(results)

Traits: AlwaysSpeculatableImplTrait

Interfaces: ConditionallySpeculatable, FPExceptionBehaviorOpInterface, NoMemoryEffect (MemoryEffectOpInterface), RoundingModeOpInterface

Effects: MemoryEffects::Effect{}

Attributes: ¶

Operands: ¶

Results: ¶

llvm.intr.copysign (LLVM::CopySignOp) ¶

Syntax:

operation ::= `llvm.intr.copysign` `(` operands `)` attr-dict `:` functional-type(operands, results)

Traits: AlwaysSpeculatableImplTrait, SameOperandsAndResultType

Interfaces: ConditionallySpeculatable, FastmathFlagsInterface, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes: ¶

Operands: ¶

Results: ¶

llvm.intr.coro.align (LLVM::CoroAlignOp) ¶

Syntax:

operation ::= `llvm.intr.coro.align` attr-dict `:` type($res)

Results: ¶

llvm.intr.coro.begin (LLVM::CoroBeginOp) ¶

Syntax:

operation ::= `llvm.intr.coro.begin` $token `,` $mem attr-dict `:` functional-type(operands, results)

Operands: ¶

Results: ¶

llvm.intr.coro.end (LLVM::CoroEndOp) ¶

Syntax:

operation ::= `llvm.intr.coro.end` $handle `,` $unwind `,` $retvals attr-dict `:` functional-type(operands, results)

Operands: ¶

Results: ¶

llvm.intr.coro.free (LLVM::CoroFreeOp) ¶

Syntax:

operation ::= `llvm.intr.coro.free` $id `,` $handle attr-dict `:` functional-type(operands, results)

Operands: ¶

Results: ¶

llvm.intr.coro.id (LLVM::CoroIdOp) ¶

Syntax:

operation ::= `llvm.intr.coro.id` $align `,` $promise `,` $coroaddr `,` $fnaddrs attr-dict `:` functional-type(operands, results)

Operands: ¶

Results: ¶

llvm.intr.coro.promise (LLVM::CoroPromiseOp) ¶

Syntax:

operation ::= `llvm.intr.coro.promise` $handle `,` $align `,` $from attr-dict `:` functional-type(operands, results)

Operands: ¶

Results: ¶

llvm.intr.coro.resume (LLVM::CoroResumeOp) ¶

Syntax:

operation ::= `llvm.intr.coro.resume` $handle attr-dict `:` qualified(type($handle))

Operands: ¶

llvm.intr.coro.save (LLVM::CoroSaveOp) ¶

Syntax:

operation ::= `llvm.intr.coro.save` $handle attr-dict `:` functional-type(operands, results)

Operands: ¶

Results: ¶

llvm.intr.coro.size (LLVM::CoroSizeOp) ¶

Syntax:

operation ::= `llvm.intr.coro.size` attr-dict `:` type($res)

Results: ¶

llvm.intr.coro.suspend (LLVM::CoroSuspendOp) ¶

Syntax:

operation ::= `llvm.intr.coro.suspend` $save `,` $final attr-dict `:` type($res)

Operands: ¶

Results: ¶

llvm.intr.cos (LLVM::CosOp) ¶

Syntax:

operation ::= `llvm.intr.cos` `(` operands `)` attr-dict `:` functional-type(operands, results)

Traits: AlwaysSpeculatableImplTrait, SameOperandsAndResultType

Interfaces: ConditionallySpeculatable, FastmathFlagsInterface, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes: ¶

Operands: ¶

Results: ¶

llvm.intr.cosh (LLVM::CoshOp) ¶

Syntax:

operation ::= `llvm.intr.cosh` `(` operands `)` attr-dict `:` functional-type(operands, results)

Traits: AlwaysSpeculatableImplTrait, SameOperandsAndResultType

Interfaces: ConditionallySpeculatable, FastmathFlagsInterface, InferTypeOpInterface, NoMemoryEffect (MemoryEffectOpInterface)

Effects: MemoryEffects::Effect{}

Attributes: ¶

Operands: ¶

Results: ¶

llvm.intr.ctlz (LLVM::CountLeadingZerosOp) ¶

Traits: AlwaysSpeculatableImplTrait, SameOperandsAndResultType