> For the complete documentation index, see [llms.txt](https://docs.zama.org/concrete/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.zama.org/concrete/2.7-1/developers/dialects/rtdialect.md).

# Runtime dialect

Runtime dialect A dialect for representation the abstraction needed for the runtime.

## Operation definition

### `RT.await_future` (::mlir::concretelang::RT::AwaitFutureOp)

Wait for a future and access its data.

The results of a dataflow task are always futures which could be further used as inputs to subsequent tasks. When the result of a task is needed in the outer execution context, the result future needs to be synchronized and its data accessed using `RT.await_future`.

#### Operands:

| Operand | Description                              |
| :-----: | ---------------------------------------- |
| `input` | Future with a parameterized element type |

#### Results:

|  Result  | Description |
| :------: | ----------- |
| `output` | any type    |

### `RT.build_return_ptr_placeholder` (::mlir::concretelang::RT::BuildReturnPtrPlaceholderOp)

#### Results:

|  Result  | Description                             |
| :------: | --------------------------------------- |
| `output` | Pointer to a parameterized element type |

### `RT.clone_future` (::mlir::concretelang::RT::CloneFutureOp)

Interfaces: AllocationOpInterface, MemoryEffectOpInterface

#### Operands:

| Operand | Description                              |
| :-----: | ---------------------------------------- |
| `input` | Future with a parameterized element type |

#### Results:

|  Result  | Description                              |
| :------: | ---------------------------------------- |
| `output` | Future with a parameterized element type |

### `RT.create_async_task` (::mlir::concretelang::RT::CreateAsyncTaskOp)

Create a dataflow task.

#### Attributes:

| Attribute |       MLIR Type       | Description                |
| :-------: | :-------------------: | -------------------------- |
|  `workfn` | ::mlir::SymbolRefAttr | symbol reference attribute |

#### Operands:

| Operand | Description |
| :-----: | ----------- |
|  `list` | any type    |

### `RT.dataflow_task` (::mlir::concretelang::RT::DataflowTaskOp)

Dataflow task operation

`RT.dataflow_task` allows to specify a task that will be concurrently executed when their operands are ready. Operands are either the results of computation in other `RT.dataflow_task` (dataflow dependences) or obtained from the execution context (immediate operands). Operands are synchronized using futures and, in the case of immediate operands, copied when the task is created. Caution is required when the operand is a pointer as no deep copy will occur.

Example:

```mlir
func @test(%0 : i64): (i64, i64) {
    // Execute right now as %0 is ready.
    %1, %2 = "RT.dataflow_task"(%0) ({
        %a = addi %0, %0 : i64
        %b = muli %0, %0 : i64
        "RT.dataflow_yield"(%a, %b) : (i64, i64) -> i64
    }) : (i64, i64) -> (i64, i64)
    // Concurrently execute both tasks below when the task above is completed.
    %3 = "RT.dataflow_task"(%1) ({
        %c = constant 1 : %i64
        %a = addi %1, %c : i64
        "RT.dataflow_yield"(%a) : (i64, i64) -> i64
    }) : (i64, i64) -> (i64, i64)
    %4 = "RT.dataflow_task"(%2) ({
        %c = constant 2 : %i64
        %a = addi %2, %c : i64
        "RT.dataflow_yield"(%a) : (i64, i64) -> i64
    }) : (i64, i64) -> (i64, i64)
    return %3, %4 : (i64, i64)
}
```

Traits: AutomaticAllocationScope, SingleBlockImplicitTerminator

Interfaces: AllocationOpInterface, MemoryEffectOpInterface, RegionBranchOpInterface

#### Operands:

|  Operand | Description |
| :------: | ----------- |
| `inputs` | any type    |

#### Results:

|   Result  | Description |
| :-------: | ----------- |
| `outputs` | any type    |

### `RT.dataflow_yield` (::mlir::concretelang::RT::DataflowYieldOp)

Dataflow yield operation

`RT.dataflow_yield` is a special terminator operation for blocks inside the region in `RT.dataflow_task`. It allows to specify the return values of a `RT.dataflow_task`.

Example:

```mlir
%0 = constant 1 : i64
%1 = constant 2 : i64
"RT.dataflow_yield" %0, %1 : i64, i64
```

Traits: ReturnLike, Terminator

#### Operands:

|  Operand | Description |
| :------: | ----------- |
| `values` | any type    |

### `RT.deallocate_future_data` (::mlir::concretelang::RT::DeallocateFutureDataOp)

#### Operands:

| Operand | Description                              |
| :-----: | ---------------------------------------- |
| `input` | Future with a parameterized element type |

### `RT.deallocate_future` (::mlir::concretelang::RT::DeallocateFutureOp)

#### Operands:

| Operand | Description |
| :-----: | ----------- |
| `input` | any type    |

### `RT.deref_return_ptr_placeholder` (::mlir::concretelang::RT::DerefReturnPtrPlaceholderOp)

#### Operands:

| Operand | Description                             |
| :-----: | --------------------------------------- |
| `input` | Pointer to a parameterized element type |

#### Results:

|  Result  | Description                              |
| :------: | ---------------------------------------- |
| `output` | Future with a parameterized element type |

### `RT.deref_work_function_argument_ptr_placeholder` (::mlir::concretelang::RT::DerefWorkFunctionArgumentPtrPlaceholderOp)

#### Operands:

| Operand | Description                             |
| :-----: | --------------------------------------- |
| `input` | Pointer to a parameterized element type |

#### Results:

|  Result  | Description |
| :------: | ----------- |
| `output` | any type    |

### `RT.make_ready_future` (::mlir::concretelang::RT::MakeReadyFutureOp)

Build a ready future.

Data passed to dataflow tasks must be encapsulated in futures, including immediate operands. These must be converted into futures using `RT.make_ready_future`.

Interfaces: AllocationOpInterface, MemoryEffectOpInterface

#### Operands:

|     Operand    | Description |
| :------------: | ----------- |
|     `input`    | any type    |
| `memrefCloned` | any type    |

#### Results:

|  Result  | Description                              |
| :------: | ---------------------------------------- |
| `output` | Future with a parameterized element type |

### `RT.register_task_work_function` (::mlir::concretelang::RT::RegisterTaskWorkFunctionOp)

Register the task work-function with the runtime system.

#### Operands:

| Operand | Description |
| :-----: | ----------- |
|  `list` | any type    |

### `RT.work_function_return` (::mlir::concretelang::RT::WorkFunctionReturnOp)

#### Operands:

| Operand | Description |
| :-----: | ----------- |
|   `in`  | any type    |
|  `out`  | any type    |

## Type definition

### FutureType

Future with a parameterized element type

The value of a `!RT.future` type represents the result of an asynchronous operation.

Examples:

```mlir
!RT.future<i64>
```

#### Parameters:

|  Parameter  | C++ type | Description |
| :---------: | :------: | ----------- |
| elementType |  `Type`  |             |

### PointerType

Pointer to a parameterized element type

#### Parameters:

|  Parameter  | C++ type | Description |
| :---------: | :------: | ----------- |
| elementType |  `Type`  |             |


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.zama.org/concrete/2.7-1/developers/dialects/rtdialect.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.