[MLIR][test] Fixup for checking for ml_dtypes (#123240)

In order to optionally run some checks that depend on the `ml_dtypes`
python module we have to remove the `CHECK` lines for those tests or
t

[MLIR][test] Fixup for checking for ml_dtypes (#123240)

In order to optionally run some checks that depend on the `ml_dtypes`
python module we have to remove the `CHECK` lines for those tests or
they will be required and missed in the test output.

I've changed to use asserts as recommended in [1].

[1]:
https://github.com/llvm/llvm-project/pull/123061#issuecomment-2596116023

show more ...

[MLIR][test] Check for ml_dtypes before running tests (#123061)

We noticed that `mlir/python/requirements.txt` lists `ml_dtypes` as a requirement but when looking at the code in `mlir/python`, the o

[MLIR][test] Check for ml_dtypes before running tests (#123061)

We noticed that `mlir/python/requirements.txt` lists `ml_dtypes` as a requirement but when looking at the code in `mlir/python`, the only `import` is guarded:

```python
try:
import ml_dtypes
except ModuleNotFoundError:
# The third-party ml_dtypes provides some optional low precision data-types for NumPy.
ml_dtypes = None
```

This makes `ml_dtypes` an optional dependency.

Some python tests however partially depend on `ml_dtypes` and should not run if that module is unavailable. That is what this change does.

This is a replacement for #123051 which was excluding tests too broadly.

show more ...

Cosmetic fixes in the code and typos in Python bindings docs (#121791)

Description:
- removed trailing spaces in few files
- fixed markdown link definition:

[mlir][CF] Split `cf-to-llvm` from `func-to-llvm` (#120580)

Do not run `cf-to-llvm` as part of `func-to-llvm`. This commit fixes
https://github.com/llvm/llvm-project/issues/70982.

This commit ch

[mlir][CF] Split `cf-to-llvm` from `func-to-llvm` (#120580)

Do not run `cf-to-llvm` as part of `func-to-llvm`. This commit fixes
https://github.com/llvm/llvm-project/issues/70982.

This commit changes the way how `func.func` ops are lowered to LLVM.
Previously, the signature of the entire region (i.e., entry block and
all other blocks in the `func.func` op) was converted as part of the
`func.func` lowering pattern.

Now, only the entry block is converted. The remaining block signatures
are converted together with `cf.br` and `cf.cond_br` as part of
`cf-to-llvm`. All unstructured control flow is not converted as part of
a single pass (`cf-to-llvm`). `func-to-llvm` no longer deals with
unstructured control flow.

Also add more test cases for control flow dialect ops.

Note: This PR is in preparation of #120431, which adds an additional
GPU-specific lowering for `cf.assert`. This was a problem because
`cf.assert` used to be converted as part of `func-to-llvm`.

Note for LLVM integration: If you see failures, add
`-convert-cf-to-llvm` to your pass pipeline.

show more ...

[mlir][Arith] Remove `arith-to-llvm` from `func-to-llvm` (#120548)

Do not run `arith-to-llvm` as part of `func-to-llvm`. This commit partly
fixes #70982.

Also simplify the pass pipeline for two

[mlir][Arith] Remove `arith-to-llvm` from `func-to-llvm` (#120548)

Do not run `arith-to-llvm` as part of `func-to-llvm`. This commit partly
fixes #70982.

Also simplify the pass pipeline for two math dialect integration tests.

Note for LLVM integration: If you see failures, add `arith-to-llvm` to your pass pipeline.

show more ...

[MLIR] Reuse the path to runner_utils libraries (#108579)

Prefer to get the path to libmlir_runner_utils and
libmlir_c_runner_utils via %mlir_runner_utils and %mlir_c_runner_utils.
Fallback to the

[MLIR] Reuse the path to runner_utils libraries (#108579)

Prefer to get the path to libmlir_runner_utils and
libmlir_c_runner_utils via %mlir_runner_utils and %mlir_c_runner_utils.
Fallback to the previous paths only if they aren't defined.

This ensures the test will pass regardless of the build configuration
used downstream.

show more ...

[MLIR][Python] add f8E5M2 and tests for np_to_memref (#106028)

add f8E5M2 and tests for np_to_memref

---------

Co-authored-by: Zhicheng Xiong <zhichengx@dc2-sim-c01-215.nvidia.com>

Reapply "[MLIR][Python] add ctype python binding support for bf16" (#101271)

Reapply the PR which was reverted due to built-bots, and now the bots
get updated.
https://discourse.llvm.org/t/need-a-

Reapply "[MLIR][Python] add ctype python binding support for bf16" (#101271)

Reapply the PR which was reverted due to built-bots, and now the bots
get updated.
https://discourse.llvm.org/t/need-a-help-with-the-built-bots/79437
original PR: https://github.com/llvm/llvm-project/pull/92489, reverted
in https://github.com/llvm/llvm-project/pull/93771

show more ...

Revert "[MLIR][Python] add ctype python binding support for bf16" (#93771)

Reverts llvm/llvm-project#92489

This broke the bots.

[MLIR][Python] add ctype python binding support for bf16 (#92489)

Since bf16 is supported by mlir, similar to
complex128/complex64/float16, we need an implementation of bf16 ctype in
Python bindin

[MLIR][Python] add ctype python binding support for bf16 (#92489)

Since bf16 is supported by mlir, similar to
complex128/complex64/float16, we need an implementation of bf16 ctype in
Python binding. Furthermore, to resolve the absence of bf16 support in
NumPy, a third-party package [ml_dtypes
](https://github.com/jax-ml/ml_dtypes) is introduced to add bf16
extension, and the same approach was used in `torch-mlir` project.

See motivation and discussion in:
https://discourse.llvm.org/t/how-to-run-executionengine-with-bf16-dtype-in-mlir-python-bindings/79025

show more ...

[mlir][Python] Fix conversion of non-zero offset memrefs to np.arrays

Memref descriptors contain an `offset` field that denotes the start of
the content of the memref relative to the `alignedPtr`. T

[mlir][Python] Fix conversion of non-zero offset memrefs to np.arrays

Memref descriptors contain an `offset` field that denotes the start of
the content of the memref relative to the `alignedPtr`. This offset is
not considered when converting a memref descriptor to a np.array in the
Python runtime library, essentially treating all memrefs as if they had
an offset of zero. This patch introduces the necessary pointer arithmetic
to find the actual beginning of the memref contents to the memref->numpy
conversion functions.

There is an ongoing discussion about whether the `offset` field is needed
at all in the memref descriptor.
Until that is decided, the Python runtime and CRunnerUtils should
still correctly implement the offset handling.

Related: https://reviews.llvm.org/D157008

Reviewed By: ftynse

Differential Revision: https://reviews.llvm.org/D158494

show more ...

[NFC][Py Reformat] Reformat python files in mlir subdir

This is an ongoing series of commits that are reformatting our
Python code.

Reformatting is done with `black`.

If you end up having problems

[NFC][Py Reformat] Reformat python files in mlir subdir

This is an ongoing series of commits that are reformatting our
Python code.

Reformatting is done with `black`.

If you end up having problems merging this commit because you
have made changes to a python file, the best way to handle that
is to run git checkout --ours <yourfile> and then reformat it
with black.

If you run into any problems, post to discourse about it and
we will try to help.

RFC Thread below:

https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style

Differential Revision: https://reviews.llvm.org/D150782

show more ...

[mlir][python] Allow running pass manager on any operation

`PassManager.run` is currently restricted to running on `builtin.module`
ops, but this restriction doesn't exist on the C++ side. This upda

[mlir][python] Allow running pass manager on any operation

`PassManager.run` is currently restricted to running on `builtin.module`
ops, but this restriction doesn't exist on the C++ side. This updates it
to take `ir.Operation/OpView` instead of `ir.Module`.

Depends on D143354

Reviewed By: mehdi_amini

Differential Revision: https://reviews.llvm.org/D143356

show more ...

[mlir][Conversion] Rename the MemRefToLLVM pass

Since the recent MemRef refactoring that centralizes the lowering of
complex MemRef operations outside of the conversion framework, the
MemRefToLLVM p

[mlir][Conversion] Rename the MemRefToLLVM pass

Since the recent MemRef refactoring that centralizes the lowering of
complex MemRef operations outside of the conversion framework, the
MemRefToLLVM pass doesn't directly convert these complex operations.

Instead, to fully convert the whole MemRef dialect space, MemRefToLLVM
needs to run after `expand-strided-metadata`.

Make this more obvious by changing the name of the pass and the option
associated with it from `convert-memref-to-llvm` to
`finalize-memref-to-llvm`.
The word "finalize" conveys that this pass needs to run after something
else and that something else is documented in its tablegen description.

This is a follow-up patch related to the conversation at:
https://discourse.llvm.org/t/psa-you-need-to-run-expand-strided-metadata-before-memref-to-llvm-now/66956/14

Differential Revision: https://reviews.llvm.org/D142463

show more ...

[mlir][python] Include anchor op in PassManager.parse

The pipeline string must now include the pass manager's anchor op. This
makes the parse API properly roundtrip the printed form of a pass
manage

[mlir][python] Include anchor op in PassManager.parse

The pipeline string must now include the pass manager's anchor op. This
makes the parse API properly roundtrip the printed form of a pass
manager.

Reviewed By: mehdi_amini

Differential Revision: https://reviews.llvm.org/D136405

show more ...

[mlir] Fix incorrect temporary file handling on windows

Reviewed By: ftynse

Differential Revision: https://reviews.llvm.org/D136364

[mlir] Fix and test python bindings for dump_to_object_file

Reviewed By: ftynse

Differential Revision: https://reviews.llvm.org/D136334

[mlir][test] Require JIT support in JIT tests

A number of mlir tests `FAIL` on Solaris/sparcv9 with `Target has no JIT
support`. This patch fixes that by mimicing `clang/test/lit.cfg.py` which
impl

[mlir][test] Require JIT support in JIT tests

A number of mlir tests `FAIL` on Solaris/sparcv9 with `Target has no JIT
support`. This patch fixes that by mimicing `clang/test/lit.cfg.py` which
implements a `host-supports-jit` keyword for this. The gtest-based unit
tests don't support `REQUIRES:`, so lack of support needs to be hardcoded
there.

Tested on `amd64-pc-solaris2.11` (`check-mlir` results unchanged) and
`sparcv9-sun-solaris2.11` (only one unrelated failure left).

Differential Revision: https://reviews.llvm.org/D131151

show more ...

[mlir] Fix macOS tests

Fix shared library names on macOS for execution_engine.py test.

Reviewed By: stellaraccident

Differential Revision: https://reviews.llvm.org/D130143

[mlir] Overhaul C/Python registration APIs to properly scope registration/loading activities.

Since the very first commits, the Python and C MLIR APIs have had mis-placed registration/load functiona

[mlir] Overhaul C/Python registration APIs to properly scope registration/loading activities.

Since the very first commits, the Python and C MLIR APIs have had mis-placed registration/load functionality for dialects, extensions, etc. This was done pragmatically in order to get bootstrapped and then just grew in. Downstreams largely bypass and do their own thing by providing various APIs to register things they need. Meanwhile, the C++ APIs have stabilized around this and it would make sense to follow suit.

The thing we have observed in canonical usage by downstreams is that each downstream tends to have native entry points that configure its installation to its preferences with one-stop APIs. This patch leans in to this approach with `RegisterEverything.h` and `mlir._mlir_libs._mlirRegisterEverything` being the one-stop entry points for the "upstream packages". The `_mlir_libs.__init__.py` now allows customization of the environment and Context by adding "initialization modules" to the `_mlir_libs` package. If present, `_mlirRegisterEverything` is treated as such a module. Others can be added by downstreams by adding a `_site_initialize_{i}.py` module, where '{i}' is a number starting with zero. The number will be incremented and corresponding module loaded until one is not found. Initialization modules can:

* Perform load time customization to the global environment (i.e. registering passes, hooks, etc).
* Define a `register_dialects(registry: DialectRegistry)` function that can extend the `DialectRegistry` that will be used to bootstrap the `Context`.
* Define a `context_init_hook(context: Context)` function that will be added to a list of callbacks which will be invoked after dialect registration during `Context` initialization.

Note that the `MLIRPythonExtension.RegisterEverything` is not included by default when building a downstream (its corresponding behavior was prior). For downstreams which need the default MLIR initialization to take place, they must add this back in to their Python CMake build just like they add their own components (i.e. to `add_mlir_python_common_capi_library` and `add_mlir_python_modules`). It is perfectly valid to not do this, in which case, only the things explicitly depended on and initialized by downstreams will be built/packaged. If the downstream has not been set up for this, it is recommended to simply add this back for the time being and pay the build time/package size cost.

CMake changes:
* `MLIRCAPIRegistration` -> `MLIRCAPIRegisterEverything` (renamed to signify what it does and force an evaluation: a number of places were incidentally linking this very expensive target)
* `MLIRPythonSoure.Passes` removed (without replacement: just drop)
* `MLIRPythonExtension.AllPassesRegistration` removed (without replacement: just drop)
* `MLIRPythonExtension.Conversions` removed (without replacement: just drop)
* `MLIRPythonExtension.Transforms` removed (without replacement: just drop)

Header changes:
* `mlir-c/Registration.h` is deleted. Dialect registration functionality is now in `IR.h`. Registration of upstream features are in `mlir-c/RegisterEverything.h`. When updating MLIR and a couple of downstreams, I found that proper usage was commingled so required making a choice vs just blind S&R.

Python APIs removed:
* mlir.transforms and mlir.conversions (previously only had an __init__.py which indirectly triggered `mlirRegisterTransformsPasses()` and `mlirRegisterConversionPasses()` respectively). Downstream impact: Remove these imports if present (they now happen as part of default initialization).
* mlir._mlir_libs._all_passes_registration, mlir._mlir_libs._mlirTransforms, mlir._mlir_libs._mlirConversions. Downstream impact: None expected (these were internally used).

C-APIs changed:
* mlirRegisterAllDialects(MlirContext) now takes an MlirDialectRegistry instead. It also used to trigger loading of all dialects, which was already marked with a TODO to remove -- it no longer does, and for direct use, dialects must be explicitly loaded. Downstream impact: Direct C-API users must ensure that needed dialects are loaded or call `mlirContextLoadAllAvailableDialects(MlirContext)` to emulate the prior behavior. Also see the `ir.c` test case (e.g. ` mlirContextGetOrLoadDialect(ctx, mlirStringRefCreateFromCString("func"));`).
* mlirDialectHandle* APIs were moved from Registration.h (which now is restricted to just global/upstream registration) to IR.h, arguably where it should have been. Downstream impact: include correct header (likely already doing so).

C-APIs added:
* mlirContextLoadAllAvailableDialects(MlirContext): Corresponds to C++ API with the same purpose.

Python APIs added:
* mlir.ir.DialectRegistry: Mapping for an MlirDialectRegistry.
* mlir.ir.Context.append_dialect_registry(MlirDialectRegistry)
* mlir.ir.Context.load_all_available_dialects()
* mlir._mlir_libs._mlirAllRegistration: New native extension that exposes a `register_dialects(MlirDialectRegistry)` entry point and performs all upstream pass/conversion/transforms registration on init. In this first step, we eagerly load this as part of the __init__.py and use it to monkey patch the Context to emulate prior behavior.
* Type caster and capsule support for MlirDialectRegistry

This should make it possible to build downstream Python dialects that only depend on a subset of MLIR. See: https://github.com/llvm/llvm-project/issues/56037

Here is an example PR, minimally adapting IREE to these changes: https://github.com/iree-org/iree/pull/9638/files In this situation, IREE is opting to not link everything, since it is already configuring the Context to its liking. For projects that would just like to not think about it and pull in everything, add `MLIRPythonExtension.RegisterEverything` to the list of Python sources getting built, and the old behavior will continue.

Reviewed By: mehdi_amini, ftynse

Differential Revision: https://reviews.llvm.org/D128593

show more ...

[mlir][python][f16] add ctype python binding support for f16

Similar to complex128/complex64, float16 has no direct support
in the ctypes implementation. This fixes the issue by using a
custom F16 t

[mlir][python][f16] add ctype python binding support for f16

Similar to complex128/complex64, float16 has no direct support
in the ctypes implementation. This fixes the issue by using a
custom F16 type to change the view in and out of MLIR code

Reviewed By: wrengr

Differential Revision: https://reviews.llvm.org/D126928

show more ...

[mlir][python][ctypes] fix ctype python binding complication for complex

There is no direct ctypes for MLIR's complex (and thus np.complex128
and np.complex64) yet, causing the mlir python binding m

[mlir][python][ctypes] fix ctype python binding complication for complex

There is no direct ctypes for MLIR's complex (and thus np.complex128
and np.complex64) yet, causing the mlir python binding methods for
memrefs to crash. This revision fixes this by passing complex arrays
as tuples of floats, correcting at the boundaries for the proper view.

NOTE: some of these changes (4 -> 2) were forced by the new "linting"

Reviewed By: mehdi_amini

Differential Revision: https://reviews.llvm.org/D126422

show more ...

[mlir] Use 'native' instead of 'llvm_has_native_target' in the mlir tests

The tests actually require the target triple to match the host, rather than just having the host in the list of available ta

[mlir] Use 'native' instead of 'llvm_has_native_target' in the mlir tests

The tests actually require the target triple to match the host, rather than just having the host in the list of available targets. This change removes `llvm_has_native_target` and instead uses the `native` feature from the lit configuration.

Reviewed By: stellaraccident

Differential Revision: https://reviews.llvm.org/D126011

show more ...

[mlir] Fix build & test of mlir python bindings on Windows

There are a couple of issues with the python bindings on Windows:
- `create_symlink` requires special permissions on Windows - using `copy_

[mlir] Fix build & test of mlir python bindings on Windows

There are a couple of issues with the python bindings on Windows:
- `create_symlink` requires special permissions on Windows - using `copy_if_different` instead allows the build to complete and then be usable
- the path to the `python_executable` is likely to contain spaces if python is installed in Program Files. llvm's python substitution adds extra quotes in order to account for this case, but mlir's own python substitution does not
- the location of the shared libraries is different on windows
- if the type is not specified for numpy arrays, they appear to be treated as strings

I've implemented the smallest possible changes for each of these in the patch, but I would actually prefer a slightly more comprehensive fix for the python_executable and the shared libraries.

For the python substitution, I think it makes sense to leverage the existing %python instead of adding %PYTHON and instead add a new variable for the case when preloading is needed. This would also make it clearer which tests are which and should be skipped on platforms where the preloading won't work.

For the shared libraries, I think it would make sense to pass the correct path and extension (possibly even the names) to the python script since these are known by lit and don't have to be hardcoded in the test at all.

Reviewed By: stellaraccident

Differential Revision: https://reviews.llvm.org/D125122

show more ...

[mlir] Fix the names of exported functions

The names of the functions that are supposed to be exported do not match the implementations. This is due in part to https://github.com/llvm/llvm-project/c

[mlir] Fix the names of exported functions

The names of the functions that are supposed to be exported do not match the implementations. This is due in part to https://github.com/llvm/llvm-project/commit/cac7aabbd8236bef2909bfc0dbba17644f7aaade.

This change makes the implementations and declarations match and adds a couple missing declarations.

The new names follow the pattern of the existing `verify` functions where the prefix is maintained as `_mlir_ciface_` but the suffix follows the new naming convention.

Reviewed By: rriddle

Differential Revision: https://reviews.llvm.org/D124891

show more ...