Refresh reference/bindings/ website pages. (#14380)
This updates the "API bindings" category of the website, focusing on:
* Which languages have API bindings, and which features those bindings
support
* Explaining API concepts with diagrams (docstrings -> reference pages
would be cool too: https://github.com/openxla/iree/issues/5477)
* Showing how to depend on IREE to use those APIs (the mechanics of
using shared libraries and C/C++ sources)
* **NOTE**: This is not fully finished yet, but I think it's ready to
checkpoint and publish as-is
| | |
|--------|--------|
| Current section | https://openxla.github.io/iree/reference/bindings/ |
| Preview of this PR |
https://scotttodd.github.io/iree/reference/bindings/ |
I'm also removing the (empty) `bindings/tensorflow-lite/` page. I'm not
aware of anyone using those bindings, and the source should have enough
comments for a motivated user to find their way :crossed_fingers:
(closes https://github.com/openxla/iree/issues/5462).
diff --git a/docs/website/docs/index.md b/docs/website/docs/index.md
index 62d9c62..a474b17 100644
--- a/docs/website/docs/index.md
+++ b/docs/website/docs/index.md
@@ -131,12 +131,9 @@
### Running models
-IREE offers a low level C API, as well as several specialized sets of
-[bindings](./reference/bindings/index.md) for running IREE models using other languages:
-
-* [C API](./reference/bindings/c-api.md)
-* [Python](./reference/bindings/python.md)
-* [TensorFlow Lite](./reference/bindings/tensorflow-lite.md)
+IREE offers a low level C API, as well as several sets of
+[API bindings](./reference/bindings/index.md) for compiling and running programs
+using various languages.
## Communication channels
diff --git a/docs/website/docs/reference/bindings/c-api.md b/docs/website/docs/reference/bindings/c-api.md
index 722aba7..7ca98b7 100644
--- a/docs/website/docs/reference/bindings/c-api.md
+++ b/docs/website/docs/reference/bindings/c-api.md
@@ -1,28 +1,306 @@
# C API bindings
-IREE provides a low level C API for its runtime[^1], which can be used directly or
-through higher level APIs and language bindings built on top of it.
+## Overview
-API header files are organized by runtime component:
+The IREE compiler and IREE runtime both have their own C/C++ APIs for use in
+other projects.
-| Component header file | Overview |
-|-----------------------------------------------------------------------------|---------------------------------------------------------------------------|
-| [iree/base/api.h](https://github.com/openxla/iree/blob/main/runtime/src/iree/base/api.h) | Core API, type definitions, ownership policies, utilities |
-| [iree/vm/api.h](https://github.com/openxla/iree/blob/main/runtime/src/iree/vm/api.h) | VM APIs: loading modules, I/O, calling functions |
-| [iree/hal/api.h](https://github.com/openxla/iree/blob/main/runtime/src/iree/hal/api.h) | HAL APIs: device management, synchronization, accessing hardware features |
+!!! note
-The [samples/](https://github.com/openxla/iree/tree/main/samples)
-directory demonstrates several ways to use IREE's C API.
+ There are multiple ways to distribute and depend on C/C++ projects, each
+ with varying levels of portability, flexibility, and toolchain
+ compatibility. IREE aims to support common configurations and platforms.
-## Prerequisites
+## Compiler API
-To use IREE's C API, you will need to build the runtime
-[from source](../../building-from-source/getting-started.md). The
-[iree-template-cpp](https://github.com/iml130/iree-template-cpp) community
-project also shows how to integrate IREE into an external project using
-CMake.
+The IREE compiler is structured as a monolithic shared object with a dynamic
+plugin system allowing for extensions. The shared object exports symbols for
+versioned API functions.
-## Concepts
+```mermaid
+graph TD
+ accTitle: IREE compiler linkage model diagram
+ accDescr {
+ The libIREECompiler.so or IREECompiler.dll shared object contains pipelines,
+ target backends, and general passes as private implementation details.
+ Compiler plugins interface with the compiler shared object to extend it with
+ custom targets, dialects, etc.
+ Applications interface with the compiler shared object through the compiler
+ C API's exported symbols.
+ }
+
+ subgraph compiler[libIREECompiler.so / IREECompiler.dll]
+ pipelines("Pipelines
+
+ • Flow
+ • Stream
+ • etc.")
+
+ targets("Target backends
+
+ • llvm-cpu
+ • vulkan-spirv
+ • etc.")
+
+ passes("General passes
+
+ • Const eval
+ • DCE
+ • etc.")
+ end
+
+ plugins("Compiler plugins
+
+ • Custom targets
+ • Custom dialects
+ • etc.")
+
+ application(Your application)
+
+ compiler <-- "Plugin API<br>(static or dynamic linking)" --> plugins
+ compiler -. "Compiler C API<br>(exported symbols)" .-> application
+```
+
+API definitions can be found in the following locations:
+
+| Source location | Overview |
+| --------------- | -------- |
+[`iree/compiler/embedding_api.h`](https://github.com/openxla/iree/blob/main/compiler/bindings/c/iree/compiler/embedding_api.h) | Top-level IREE compiler embedding API
+[`iree/compiler/PluginAPI/` directory](https://github.com/openxla/iree/tree/main/compiler/src/iree/compiler/PluginAPI) | IREE compiler plugin API
+[`mlir/include/mlir-c/` directory](https://github.com/llvm/llvm-project/tree/main/mlir/include/mlir-c) | MLIR C API headers
+
+### Concepts
+
+The compiler API is centered around running pipelines to translate inputs to
+artifacts. These are modeled via _sessions_, _invocations_, _sources_, and
+_outputs_.
+
+```mermaid
+stateDiagram-v2
+ accTitle: IREE compiler session and invocation state diagram
+ accDescr {
+ Input files are opened (or buffers are wrapped) as sources in a session.
+ Sources are parsed into invocations, which run pipelines.
+ Output files are written (or buffers are mapped) for compilation artifacts.
+ }
+
+ direction LR
+ InputFile --> Source1 : open file
+ InputBuffer --> Source2 : wrap buffer
+
+ state Session {
+ Source1 --> Invocation1
+ Source1 --> Invocation2
+ Source2 --> Invocation3
+ Invocation1 --> Invocation1 : run pipeline
+ Invocation2 --> Invocation2 : run pipeline
+ Invocation3 --> Invocation3 : run pipeline
+ }
+
+ Invocation1 --> OutputFile1 : write file
+ Invocation2 --> OutputBuffer1 : map memory
+ Invocation3 --> OutputBuffer2 : map memory
+```
+
+#### Sessions
+
+A _session_ represents a scope where one or more invocations can be executed.
+
+* Internally, _sessions_ consist of an `MLIRContext` and a private set of
+ _options_.
+* _Sessions_ may activate available _plugins_ based on their _options_.
+
+#### Invocations
+
+An _invocation_ represents a discrete run of the compiler.
+
+* _Invocations_ run _pipelines_, consisting of _passes_, to translate from
+ _sources_ to _outputs_.
+
+#### Sources
+
+A _source_ represents an input program, including operations and data.
+
+* _Sources_ may refer to files or buffers in memory.
+
+#### Outputs
+
+An _output_ represents a compilation artifact.
+
+* _Outputs_ can be standalone files or more advanced streams.
+
+#### Plugins
+
+A _plugin_ extends the compiler with some combination of target backends,
+options, passes, or pipelines.
+
+### Usage
+
+!!! todo - "Under construction, more coming soon"
+
+!!! Tip "Tip - building from source"
+
+ When [building from source](../../building-from-source/getting-started.md),
+ some components may be disabled to reduce binary size and improve build
+ time. There are also options for using your own LLVM or linking in external
+ target backends.
+
+#### Samples
+
+| Project | Source | Description |
+| ------- |------- | ----------- |
+[openxla-pjrt-plugin](https://github.com/openxla/openxla-pjrt-plugin/) | [`iree_compiler.cc`](https://github.com/openxla/openxla-pjrt-plugin/blob/main/iree/integrations/pjrt/common/iree_compiler.cc) | JIT engine connecting TensorFlow and JAX to IREE
+
+## Runtime API
+
+The IREE runtime is structured as a modular set of library components. Each
+component is designed to be linked into applications directly and compiled
+with LTO style optimizations.
+
+The low level library components can be used directly or through a higher level
+API.
+
+=== "High level API"
+
+ The high level 'runtime' API sits on top of the low level components. It is
+ relatively terse but does not expose the full flexibility of the underlying
+ systems.
+
+ ```mermaid
+ graph TD
+ accTitle: IREE runtime high level API diagram
+ accDescr {
+ The IREE runtime includes 'base', 'HAL', and 'VM' components, each with
+ their own types and API methods.
+ A high level "runtime API" sits on top of these component APIs.
+ Applications can interface indirectly with the IREE runtime via this
+ high level runtime API.
+ }
+
+ subgraph iree_runtime[IREE Runtime]
+ subgraph base
+ base_types("Types
+
+ • allocator
+ • status
+ • etc.")
+ end
+
+ subgraph hal[HAL]
+ hal_types("Types
+
+ • buffer
+ • device
+ • etc.")
+
+ hal_drivers("Drivers
+
+ • local-*
+ • vulkan
+ • etc.")
+ end
+
+ subgraph vm[VM]
+ vm_types("Types
+
+ • context
+ • invocation
+ • etc.")
+ end
+
+ runtime_api("Runtime API
+
+ • instance
+ • session
+ • call")
+
+ base_types & hal_types & hal_drivers & vm_types --> runtime_api
+ end
+
+ application(Your application)
+
+ runtime_api --> application
+ ```
+
+=== "Low level API"
+
+ Each runtime component has its own low level API. The low level APIs are
+ typically verbose as they expose the full flexibility of each underlying
+ system.
+
+ ```mermaid
+ graph TD
+ accTitle: IREE runtime low level API diagram
+ accDescr {
+ The IREE runtime includes 'base', 'HAL', and 'VM' components, each with
+ their own types and API methods.
+ Applications can interface directly with the IREE runtime via the low
+ level component APIs.
+ }
+
+ subgraph iree_runtime[IREE Runtime]
+ subgraph base
+ base_types("Types
+
+ • allocator
+ • status
+ • etc.")
+ end
+ subgraph hal[HAL]
+ hal_types("Types
+
+ • buffer
+ • device
+ • etc.")
+
+ hal_drivers("Drivers
+
+ • local-*
+ • vulkan
+ • etc.")
+ end
+ subgraph vm[VM]
+ vm_types("Types
+
+ • context
+ • invocation
+ • etc.")
+ end
+ end
+
+ application(Your application)
+
+ base_types & hal_types & hal_drivers & vm_types --> application
+ ```
+
+Runtime API header files are organized by component:
+
+| Component header file | Overview |
+| --------------------- | -------- |
+[`iree/runtime/api.h`](https://github.com/openxla/iree/blob/main/runtime/src/iree/runtime/api.h) | High level runtime API
+[`iree/base/api.h`](https://github.com/openxla/iree/blob/main/runtime/src/iree/base/api.h) | Core API, type definitions, ownership policies, utilities
+[`iree/vm/api.h`](https://github.com/openxla/iree/blob/main/runtime/src/iree/vm/api.h) | VM APIs: loading modules, I/O, calling functions
+[`iree/hal/api.h`](https://github.com/openxla/iree/blob/main/runtime/src/iree/hal/api.h) | HAL APIs: device management, synchronization, accessing hardware features
+
+### Concepts
+
+<!-- TODO(scotttodd): high level runtime API diagram(s) -->
+
+#### High level - Session
+
+!!! todo - "Under construction, more coming soon"
+
+#### High level - Instance
+
+!!! todo - "Under construction, more coming soon"
+
+#### High level - Call
+
+!!! todo - "Under construction, more coming soon"
+
+#### Low level - VM
+
+<!-- TODO(scotttodd): VM module diagram (bytecode, HAL, custom) -->
By default, IREE uses its own tiny Virtual Machine (VM) at runtime to interpret
program instructions on the host system. VM instructions may also be lowered
@@ -30,15 +308,8 @@
constrained deployment.
The VM supports generic operations like loads, stores, arithmetic, function
-calls, and control flow. It builds streams of more complex program logic and
-dense math into command buffers that are dispatched to hardware backends
-through the Hardware Abstraction Layer (HAL) interface.
-
-Most interaction with IREE's C API involves either the VM or the HAL.
-
-<!-- TODO(scotttodd): diagrams -->
-
-### IREE VM
+calls, and control flow. The VM builds streams of more complex program logic and
+dense math into HAL command buffers that are dispatched to hardware backends.
* VM _instances_ can serve multiple isolated execution _contexts_
* VM _contexts_ are effectively sandboxes for loading modules and running
@@ -47,7 +318,11 @@
access to hardware accelerators through the HAL. Compiled user programs are
also modules.
-### IREE HAL
+#### Low level - HAL
+
+<!-- TODO(scotttodd): command buffer construction -> dispatch diagram -->
+<!-- TODO(scotttodd): input buffers -> output buffers diagram -->
+<!-- TODO(scotttodd): HAL interface diagram -->
* HAL _drivers_ are used to enumerate and create HAL _devices_
* HAL _devices_ interface with hardware, such as by allocating device memory,
@@ -56,161 +331,23 @@
* HAL _buffers_ and _buffer views_ represent storage and shaped/typed views
into that storage (aka "tensors")
-## Using the C API
+### Usage
-### Setup
+!!! todo - "Under construction, more coming soon"
-Include headers:
+#### Samples
-``` c
-#include "iree/base/api.h"
-#include "iree/hal/api.h"
-#include "iree/vm/api.h"
+| Source location | Description |
+| --------------- | ----------- |
+[iree `runtime/demo/`](https://github.com/openxla/iree/blob/main/runtime/src/iree/runtime/demo/) | In-tree demos of the high level runtime API
+[iree `samples/`](https://github.com/openxla/iree/tree/main/samples) | In-tree sample applications
+[iree-template-runtime-cmake](https://github.com/benvanik/iree-template-runtime-cmake/) | Template repository for runtime applications
+[iree-template-cpp](https://github.com/iml130/iree-template-cpp) | Demonstration of integration into a downstream project
+[iree-samples `runtime-library/`](https://github.com/iree-org/iree-samples/tree/main/runtime-library) | Shared runtime library builder
-// The VM bytecode and HAL modules will typically be included, along
-// with those for the specific HAL drivers your application uses.
-// Functionality extensions can be used via custom modules.
-#include "iree/modules/hal/module.h"
-#include "iree/hal/drivers/local_task/registration/driver_module.h"
-#include "iree/vm/bytecode/module.h"
-```
+## Compiler + Runtime = JIT
-Check the API version and register components:
-
-``` c
-// Device drivers are managed through registries.
-// Applications may use multiple registries to more finely control driver
-// lifetimes and visibility.
-IREE_CHECK_OK(iree_hal_local_task_driver_module_register(
- iree_hal_driver_registry_default()));
-```
-
-!!! tip
- The `IREE_CHECK_OK()` macro calls `assert()` if an error occurs.
- Applications should propagate errors and handle or report them as desired.
-
-### Configure stateful objects
-
-Create a VM instance along with a HAL driver and device:
-
-``` c
-// Applications should try to reuse instances so resource usage across contexts
-// is handled and extraneous device interaction is avoided.
-iree_vm_instance_t* instance = NULL;
-IREE_CHECK_OK(iree_vm_instance_create(iree_allocator_system(), &instance));
-
-// Modules with custom types must be statically registered before use.
-IREE_CHECK_OK(iree_hal_module_register_all_types(instance));
-
-// We use the CPU "local-task" driver in this example, but could use a different
-// driver like the GPU "vulkan" driver. The driver(s) used should match with
-// the target(s) specified during compilation.
-iree_hal_driver_t* driver = NULL;
-IREE_CHECK_OK(iree_hal_driver_registry_try_create(
- iree_hal_driver_registry_default(),
- iree_string_view_literal("local-task"),
- iree_allocator_system(), &driver));
-
-// Drivers may support multiple devices, such as when a machine has multiple
-// GPUs. You may either enumerate devices and select based on their properties,
-// or just use the default device.
-iree_hal_device_t* device = NULL;
-IREE_CHECK_OK(iree_hal_driver_create_default_device(
- driver, iree_allocator_system(), &device));
-
-// Create a HAL module initialized to use the newly created device.
-// We'll load this module into a VM context later.
-iree_vm_module_t* hal_module = NULL;
-IREE_CHECK_OK(
- iree_hal_module_create(instance, device, IREE_HAL_MODULE_FLAG_NONE,
- iree_allocator_system(), &hal_module));
-// The reference to the driver can be released now.
-iree_hal_driver_release(driver);
-```
-
-!!! tip
- The default `iree_allocator_system()` is backed by `malloc` and `free`,
- but custom allocators may also be used.
-
-Load a vmfb bytecode module containing program data:
-
-``` c
-// (Application-specific loading into memory, such as loading from a file)
-
-iree_vm_module_t* bytecode_module = NULL;
-IREE_CHECK_OK(iree_vm_bytecode_module_create(
- instance,
- iree_const_byte_span_t{module_data, module_size},
- /*flatbuffer_allocator=*/iree_allocator_null(),
- /*allocator=*/iree_allocator_system(), &bytecode_module));
-```
-
-!!! note
- Many IREE samples use
- [`c_embed_data`](https://github.com/openxla/iree/tree/main/build_tools/embed_data)
- to embed vmfb files as C code to avoid file I/O and ease portability.
- Applications should use what makes sense for their platforms and deployment
- configurations.
-
-Create a VM context and load modules into it:
-
-``` c
-iree_vm_context_t* context = NULL;
-iree_vm_module_t* modules[2] = {hal_module, bytecode_module};
-IREE_CHECK_OK(iree_vm_context_create_with_modules(
- instance, IREE_VM_CONTEXT_FLAG_NONE,
- IREE_ARRAYSIZE(modules), modules,
- iree_allocator_system(), &context));
-// References to the modules can be released now.
-iree_vm_module_release(hal_module);
-iree_vm_module_release(bytecode_module);
-```
-
-Look up the function(s) to call:
-
-``` c
-iree_vm_function_t main_function;
-IREE_CHECK_OK(iree_vm_context_resolve_function(
- context, iree_string_view_literal("module.main_function"), &main_function));
-```
-
-### Invoke functions
-
-<!-- TODO(scotttodd): I/O buffers (TODO pending new helpers) -->
-
-``` c
-// (Application-specific I/O buffer setup, making data available to the device)
-
-IREE_CHECK_OK(iree_vm_invoke(context, main_function, IREE_VM_INVOCATION_FLAG_NONE,
- /*policy=*/NULL, inputs, outputs,
- iree_allocator_system()));
-
-// (Application-specific output buffer retrieval and reading back from the device)
-```
-
-### Cleanup resources
-
-``` c
-iree_hal_device_release(device);
-iree_vm_context_release(context);
-iree_vm_instance_release(instance);
-```
-
-<!-- ## Advanced usage -->
-
-<!-- TODO(scotttodd): async execution and synchronization -->
-<!-- TODO(scotttodd): specialized HAL APIs -->
-<!-- TODO(scotttodd): threadpools -->
-<!-- TODO(scotttodd): heterogenous execution -->
-
-<!-- ## Troubleshooting -->
-
-<!-- TODO(scotttodd): link to GitHub issues -->
-<!-- TODO(scotttodd): compiler/runtime compatibility -->
-<!-- TODO(scotttodd): common problems? object ownership? loaded modules (HAL)? -->
-
-[^1]:
- We also have a C API for IREE's compiler, see
- [this GitHub issue](https://github.com/openxla/iree/issues/3817)
-
-*[vmfb]: VM FlatBuffer
+The compiler and runtime APIs may be used together to build a "just in time"
+(JIT) execution engine. JIT compilation allows for last-minute specialization
+with no prior knowledge of target devices and avoids issues with version drift,
+but it can also constrain deployment options and usage scenarios.
diff --git a/docs/website/docs/reference/bindings/index.md b/docs/website/docs/reference/bindings/index.md
index c2ae5e2..6b4ed10 100644
--- a/docs/website/docs/reference/bindings/index.md
+++ b/docs/website/docs/reference/bindings/index.md
@@ -1,8 +1,61 @@
# API bindings
-IREE offers specialized sets of bindings for running compiled programs from
-various languages or with specific APIs:
+API bindings allow for programmatic use of IREE's compiler and runtime
+components. The core IREE project is written in C[^1], allowing for API bindings
+to be written in a variety of other languages.
-* [Runtime C API](./c-api.md)
-* [Compiler and runtime Python bindings](./python.md)
-* [Runtime TensorFlow Lite bindings](./tensorflow-lite.md)
+!!! question - "Something missing?"
+
+ Want to use another language? Looking for something specific out of one of
+ those already listed?
+
+ We welcome discussions on our
+ [communication channels](../../index.md#communication-channels) and
+ contributions on [our GitHub page](https://github.com/openxla/iree)!
+
+## Official API bindings
+
+Members of the core project team and OpenXLA partners maintain these official
+bindings:
+
+Language | Compiler API? | Runtime API? | Published packages?
+-------- | ------------ | ----------- | ------------------
+[C/C++](#cc) | :white_check_mark: Supported | :white_check_mark: Supported | :x: Unsupported
+[Python](#python) | :white_check_mark: Supported | :white_check_mark: Supported | :white_check_mark: Supported
+[JavaScript](#javascript) | :grey_question: Experimental | :grey_question: Experimental | :x: Unsupported
+
+### C/C++
+
+See the [C API](./c-api.md) reference page.
+
+### :simple-python: Python
+
+See the [Python](./python.md) reference page.
+
+### :simple-javascript: JavaScript
+
+* JavaScript bindings for WebAssembly and WebGPU are under development in IREE's
+[`experimental/web/`](https://github.com/openxla/iree/tree/main/experimental/web)
+directory.
+
+## Unofficial API bindings
+
+Members of our developer community have authored bindings using other languages:
+
+Language | Compiler API? | Runtime API? | Published packages?
+-------- | ------------ | ----------- | ------------------
+[Julia](#julia) | :grey_question: Experimental | :grey_question: Experimental | :x: Unsupported
+[Rust](#rust) | :x: Unsupported | :grey_question: Experimental | :grey_question: Experimental
+
+### :simple-julia: Julia
+
+* [Coil.jl](https://github.com/Pangoraw/Coil.jl) is an experimental package to
+lower and execute Julia tensor operations to IREE.
+
+### :simple-rust: Rust
+
+* [iree-rs](https://github.com/SamKG/iree-rs) is
+[a crate](https://crates.io/crates/iree-rs) containing rustic bindings for the
+IREE runtime.
+
+[^1]: with some C++ tools and utilities
diff --git a/docs/website/docs/reference/bindings/python.md b/docs/website/docs/reference/bindings/python.md
index 59a096b..9bf655a 100644
--- a/docs/website/docs/reference/bindings/python.md
+++ b/docs/website/docs/reference/bindings/python.md
@@ -111,6 +111,48 @@
and the [iree-samples repository](https://github.com/iree-org/iree-samples) for
examples using the Python APIs.
-<!-- ## Troubleshooting -->
+### Quickstart
-<!-- TODO(scotttodd): update python, update pip, search GitHub issues -->
+[](https://colab.research.google.com/github/openxla/iree/blob/main/samples/colab/low_level_invoke_function.ipynb)
+
+Compile a program:
+
+```python
+from iree import compiler as ireec
+
+# Compile a module.
+INPUT_MLIR = """
+module @arithmetic {
+ func.func @simple_mul(%arg0: tensor<4xf32>, %arg1: tensor<4xf32>) -> tensor<4xf32> {
+ %0 = arith.mulf %arg0, %arg1 : tensor<4xf32>
+ return %0 : tensor<4xf32>
+ }
+}
+"""
+
+# Compile using the vmvx (reference) target:
+compiled_flatbuffer = ireec.tools.compile_str(
+ INPUT_MLIR,
+ target_backends=["vmvx"])
+```
+
+Run a compiled program:
+
+```python
+from iree import runtime as ireert
+
+# Register the module with a runtime context.
+# Use the "local-task" CPU driver, which can load the vmvx executable:
+config = ireert.Config("local-task")
+ctx = ireert.SystemContext(config=config)
+vm_module = ireert.VmModule.copy_buffer(ctx.instance, compiled_flatbuffer)
+ctx.add_vm_module(vm_module)
+
+# Invoke the function and print the result.
+print("INVOKE simple_mul")
+arg0 = np.array([1., 2., 3., 4.], dtype=np.float32)
+arg1 = np.array([4., 5., 6., 7.], dtype=np.float32)
+f = ctx.modules.arithmetic["simple_mul"]
+results = f(arg0, arg1).to_host()
+print("Results:", results)
+```
diff --git a/docs/website/docs/reference/bindings/tensorflow-lite.md b/docs/website/docs/reference/bindings/tensorflow-lite.md
deleted file mode 100644
index 901c612..0000000
--- a/docs/website/docs/reference/bindings/tensorflow-lite.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-hide:
- - tags
-tags:
- - TensorFlow
----
-
-# TensorFlow Lite bindings
-
-!!! todo
- [Issue#5462](https://github.com/openxla/iree/issues/5462): write this documentation
-
-<!-- TODO(??): overview, advantages/disadvantages to using TFLite bindings -->
-
-<!-- TODO(??): build from source, Android AAR -->
-
-<!-- TODO(??): troubleshooting -->
diff --git a/docs/website/docs/reference/glossary.md b/docs/website/docs/reference/glossary.md
index 16f3d9b..4852d5c 100644
--- a/docs/website/docs/reference/glossary.md
+++ b/docs/website/docs/reference/glossary.md
@@ -114,6 +114,8 @@
[TFLite Integration guide](../guides/ml-frameworks/tflite.md) for details on how
to use TFLite programs with IREE.
-IREE also provides runtime bindings for the
+IREE also has bindings for the
[TFLite C API](https://github.com/tensorflow/tensorflow/tree/master/tensorflow/lite/c),
-see the [TensorFlow Lite bindings](./bindings/tensorflow-lite.md) page.
+see the
+[`runtime/bindings/tflite/`](https://github.com/openxla/iree/tree/main/runtime/bindings/tflite)
+directory for details.
diff --git a/docs/website/docs/reference/index.md b/docs/website/docs/reference/index.md
index 2c20a04..a5d1a50 100644
--- a/docs/website/docs/reference/index.md
+++ b/docs/website/docs/reference/index.md
@@ -2,19 +2,10 @@
## API bindings
-!!! info ""
+IREE offers API bindings for compiling and running programs from various
+languages.
- IREE offers API bindings for both compiling and running programs from
- various languages or with specific APIs.
-
-Supported languages:
-
-* [Runtime C API](./bindings/c-api.md)
-* [Compiler and runtime Python bindings](./bindings/python.md)
-
-Supported framework APIs:
-
-* [Runtime TensorFlow Lite bindings](./bindings/tensorflow-lite.md)
+* [Index page](./bindings/index.md)
## MLIR dialects
diff --git a/docs/website/mkdocs.yml b/docs/website/mkdocs.yml
index 64affe2..1431d9a 100644
--- a/docs/website/mkdocs.yml
+++ b/docs/website/mkdocs.yml
@@ -139,9 +139,8 @@
- "reference/index.md"
- "API bindings":
- "reference/bindings/index.md"
- - Runtime C API: "reference/bindings/c-api.md"
+ - C API: "reference/bindings/c-api.md"
- Python: "reference/bindings/python.md"
- - TensorFlow Lite: "reference/bindings/tensorflow-lite.md"
- "MLIR dialects":
- "reference/mlir-dialects/index.md"
# Note: these files are generated by generate_extra_files.sh.
@@ -201,7 +200,6 @@
"bindings/index.md": "reference/bindings/index.md"
"bindings/c-api.md": "reference/bindings/c-api.md"
"bindings/python.md": "reference/bindings/python.md"
- "bindings/tensorflow-lite.md": "reference/bindings/tensorflow-lite.md"
# "blog/" moved under "community/"
"blog/index.md": "community/blog/index.md"
