Lines Matching full:can
43 # The pip version can be obtained with `python -m pip --version`, and for
86 composable modules that downstream integrators can include and re-export into
104 translation unit. Breaking into multiple translation units can significantly aid
137 that one-time initialization code can be invoked apart from module constructors.
195 increases the chances that interesting DSLs and higher level APIs can be
204 As mentioned above, `PyOperation` is special because it can exist in either a
205 top-level or dependent state. The life-cycle is unidirectional: operations can
216 for regions and blocks and needs to be a top-level type that we can count on not
233 With the way it is now, we can avoid having a global live list for regions and
236 objects. We can cross that bridge easily when we get there.
238 Module, when used purely from the Python API, can't alias anyway, so we can use
253 can be overridden by specific calls through the dedicated keyword arguments.
260 manager, one can write:
315 Both can be provided using context managers or explicitly as keyword arguments
316 in the operation constructor. They can be also provided as keyword arguments
343 Note that `Location` needs an MLIR context to be constructed. It can take the
368 for. One can traverse the IR operation/region/block structure and inspect their
380 Given an `OpView` subclass, one can obtain an `Operation` using its `.operation`
381 property. Given an `Operation`, one can obtain the corresponding `OpView` using
386 One can check if an operation has a specific type by means of Python's
398 The components of an operation can be inspected using its properties.
400 - `attributes` is a collection of operation attributes . It can be subscripted
440 thus iterable, which provides access to the blocks. One can also use the
456 alive. This operation can be accessed using the `.owner` property.
468 Given an `Attribute` or `Type` object, one can obtain a concrete subclass using
486 method to check whether an object of the opaque `Attribute` or `Type` type can
507 readonly properties. For example, the elemental type of a tensor type can be
544 counterparts. Objects of these classes can be constructed from either:
574 # An interface object can also be constructed given an OpView subclass. It
576 # can be provided explicitly or set up by the surrounding context manager.
590 # One can still call static interface methods though.
607 Operations can be created given a `Location` and an optional `InsertionPoint`.
611 Concrete operations can be created by using constructors of the corresponding
630 operations may omit the `results` argument, so can the operations where the
631 result types can be derived from operand types unambiguously. As a concrete
632 example, built-in function operations can be constructed by providing a function
647 Operations can also be constructed using the generic class and based on the
661 # Operations can be created in a generic way.
675 Blocks can be created within a given region and inserted before or after another
694 Blocks can be used to create `InsertionPoint`s, which can point to the beginning
696 `OpView` subclasses to provide a `.body` property that can be used to construct
702 Attributes and types can be created given a `Context` or another attribute or
734 Builtin attribute can often be constructed from Python types with similar
735 structure. For example, `ArrayAttr` can be constructed from a sequence
736 collection of attributes, and a `DictAttr` can be constructed from a dictionary:
746 Custom builders for Attributes to be used during Operation creation can be
765 type (e.g., I32Attr can have only one, which can correspond to multiple of the
803 reasonable printed form, it can be a significant productivity boost to wire that
809 a mechanical concession to Python style, this can go a long way to making the
847 Note that this can be taken too far, so use good judgment. For example, block
854 One stop helpers that aggregate over multiple low level entities can be
857 construct a SourceMgr can be quite nice. One stop helpers do not have to be
948 dialects can add their modules to the search path by calling:
1015 `operands`. This can be used to get some default construction semantics for
1098 can be exposed to Python as a submodule of `mlir.dialects` and interoperate with
1101 of boilerplate APIs can be generated from ODS. For dialects containing
1105 manager, which may be done at Python module load time. Other functionality can
1124 can be extended as described above. MLIR provides [CMake
1139 subclasses can be defined using
1146 and `MlirType` and their Python counterparts so that the C API handles can be
1150 The attribute and type bindings for a dialect can be located in
1163 Dialect-specific passes can be made available to the pass manager in Python by
1165 parsing from string descriptions. This can be achieved by creating a new
1171 which can be `import`ed from the main dialect file, i.e.
1182 can be exposed to Python similarly to attributes and types. C API is expected to
1183 exist for this functionality, which can then be wrapped using pybind11 and
1187 utilities to connect to the rest of Python API. The bindings can be located in a