Lines Matching defs:API
77 the ability to `import mlir` and use the API in a pure way out of the box.
79 1. Downstream integrations will likely want to include parts of the API in
148 ### Use the C-API
150 The Python APIs should seek to layer on top of the C-API to the degree possible.
224 The C/C++ API allows for Region/Block to also be detached, but it simplifies the
225 ownership model a lot to eliminate that possibility in this API, allowing the
238 Module, when used purely from the Python API, can't alias anyway, so we can use
239 it as a top-level ref type without a live-list for interning. If the API ever
243 ## User-level API
277 cannot be extracted from any argument, the bindings API expects the (keyword)
810 API feel like it fits in with its peers in the Python landscape.
850 complicated. If running into these, just mirror the C/C++ API.
873 * For convenience, we also test non-generative API interactions with the same
984 the API does some light validation on this but the primary purpose is to
1102 attributes and types, it is necessary to thread those through the C API since
1106 be provided, similar to attributes and types, by exposing the relevant C API and
1107 building Python API on top.
1114 properties. Therefore, there is no need to implement a separate C API for them.
1116 -bind-dialect=<dialect-namespace>` generates the Python API from the declarative
1143 utilities that mimic pybind11/nanobind API for defining functions and
1145 utilities also provide automatic casting between C API handles `MlirAttribute`
1146 and `MlirType` and their Python counterparts so that the C API handles can be
1164 registering them with the context and relying on the API for pass pipeline
1167 calls the registration C API, which must be provided first. For passes defined
1169 `-mlir-tblgen -gen-pass-capi-impl` automate the generation of C API. The
1182 can be exposed to Python similarly to attributes and types. C API is expected to
1187 utilities to connect to the rest of Python API. The bindings can be located in a