[MLIR][Python] add ctype python binding support for bf16

[xurui1995]

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 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

[github-actions]

Thank you for submitting a Pull Request (PR) to the LLVM Project!

This PR will be automatically labeled and the relevant teams will be
notified.

If you wish to, you can add reviewers by using the "Reviewers" section on this page.

If this is not working for you, it is probably because you do not have write
permissions for the repository. In which case you can instead tag reviewers by
name in a comment by using @ followed by their GitHub username.

If you have received no comments on your PR for a week, you can request a review
by "ping"ing the PR by adding a comment “Ping”. The common courtesy "ping" rate
is once a week. Please remember that you are asking for valuable time from other developers.

If you have further questions, they may be answered by the LLVM GitHub User Guide.

You can also ask questions in a comment on this PR, on the LLVM Discord or on the forums.

[llvmbot]

@llvm/pr-subscribers-mlir

Author: Bimo (xurui1995)

Changes

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 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

---

Full diff: https://github.com/llvm/llvm-project/pull/92489.diff

3 Files Affected:

• (modified) mlir/python/mlir/runtime/np_to_memref.py (+10)
• (modified) mlir/python/requirements.txt (+2-1)
• (modified) mlir/test/python/execution_engine.py (+51)

diff --git a/mlir/python/mlir/runtime/np_to_memref.py b/mlir/python/mlir/runtime/np_to_memref.py
index f6b706f9bc8ae..55e6a6cc5ab3e 100644
--- a/mlir/python/mlir/runtime/np_to_memref.py
+++ b/mlir/python/mlir/runtime/np_to_memref.py
@@ -6,6 +6,7 @@
 
 import numpy as np
 import ctypes
+import ml_dtypes
 
 
 class C128(ctypes.Structure):
@@ -25,6 +26,11 @@ class F16(ctypes.Structure):
 
     _fields_ = [("f16", ctypes.c_int16)]
 
+class BF16(ctypes.Structure):
+    """A ctype representation for MLIR's BFloat16."""
+
+    _fields_ = [("bf16", ctypes.c_int16)]
+
 
 # https://stackoverflow.com/questions/26921836/correct-way-to-test-for-numpy-dtype
 def as_ctype(dtp):
@@ -35,6 +41,8 @@ def as_ctype(dtp):
         return C64
     if dtp == np.dtype(np.float16):
         return F16
+    if dtp == ml_dtypes.bfloat16:
+        return BF16
     return np.ctypeslib.as_ctypes_type(dtp)
 
 
@@ -46,6 +54,8 @@ def to_numpy(array):
         return array.view("complex64")
     if array.dtype == F16:
         return array.view("float16")
+    if array.dtype == BF16:
+        return array.view("bfloat16")
     return array
 
 
diff --git a/mlir/python/requirements.txt b/mlir/python/requirements.txt
index acd6dbb25edaf..90acba8d65f09 100644
--- a/mlir/python/requirements.txt
+++ b/mlir/python/requirements.txt
@@ -1,3 +1,4 @@
 numpy>=1.19.5, <=1.26
 pybind11>=2.9.0, <=2.10.3
-PyYAML>=5.3.1, <=6.0.1
\ No newline at end of file
+PyYAML>=5.3.1, <=6.0.1
+ml_dtypes
\ No newline at end of file
diff --git a/mlir/test/python/execution_engine.py b/mlir/test/python/execution_engine.py
index e8b47007a8907..61d145ef24d95 100644
--- a/mlir/test/python/execution_engine.py
+++ b/mlir/test/python/execution_engine.py
@@ -5,6 +5,7 @@
 from mlir.passmanager import *
 from mlir.execution_engine import *
 from mlir.runtime import *
+from ml_dtypes import bfloat16
 
 
 # Log everything to stderr and flush so that we have a unified stream to match
@@ -521,6 +522,56 @@ def testComplexUnrankedMemrefAdd():
 run(testComplexUnrankedMemrefAdd)
 
 
+# Test addition of two bf16 memrefs
+# CHECK-LABEL: TEST: testBF16MemrefAdd
+def testBF16MemrefAdd():
+    with Context():
+        module = Module.parse(
+            """
+    module  {
+      func.func @main(%arg0: memref<1xcomplex<bf16>>,
+                      %arg1: memref<1xcomplex<bf16>>,
+                      %arg2: memref<1xcomplex<bf16>>) attributes { llvm.emit_c_interface } {
+        %0 = arith.constant 0 : index
+        %1 = memref.load %arg0[%0] : memref<1xcomplex<bf16>>
+        %2 = memref.load %arg1[%0] : memref<1xcomplex<bf16>>
+        %3 = complex.add %1, %2 : complex<bf16>
+        memref.store %3, %arg2[%0] : memref<1xcomplex<bf16>>
+        return
+      }
+    } """
+        )
+
+        arg1 = np.array([11.0]).astype(bfloat16)
+        arg2 = np.array([12.0]).astype(bfloat16)
+        arg3 = np.array([0.0]).astype(bfloat16)
+
+        arg1_memref_ptr = ctypes.pointer(
+            ctypes.pointer(get_ranked_memref_descriptor(arg1))
+        )
+        arg2_memref_ptr = ctypes.pointer(
+            ctypes.pointer(get_ranked_memref_descriptor(arg2))
+        )
+        arg3_memref_ptr = ctypes.pointer(
+            ctypes.pointer(get_ranked_memref_descriptor(arg3))
+        )
+
+        execution_engine = ExecutionEngine(lowerToLLVM(module))
+        execution_engine.invoke(
+            "main", arg1_memref_ptr, arg2_memref_ptr, arg3_memref_ptr
+        )
+        # CHECK: [11.] + [22.] = [33.]
+        log("{0} + {1} = {2}".format(arg1, arg2, arg3))
+
+        # test to-numpy utility
+        # CHECK: [33.]
+        npout = ranked_memref_to_numpy(arg3_memref_ptr[0])
+        log(npout)
+
+
+run(testBF16MemrefAdd)
+
+
 #  Test addition of two 2d_memref
 # CHECK-LABEL: TEST: testDynamicMemrefAdd2D
 def testDynamicMemrefAdd2D():

[stellaraccident]

Thanks for the PR. I don't think we want to globally add a dep like this as it will impact everyone.

The traditional was to do this would be to do the import in a try...except, setting a flag on failure. Then skip the integration of it is not available.

[ftynse]

Is this something that can be added to https://github.com/llvm/llvm-project/blob/main/mlir/python/requirements.txt ?

[xurui1995]

Is this something that can be added to https://github.com/llvm/llvm-project/blob/main/mlir/python/requirements.txt ?

Is this something that can be added to https://github.com/llvm/llvm-project/blob/main/mlir/python/requirements.txt ?

Hi, @ftynse
The dependency was added in the requirements.txt in the initial commit. However, as @stellaraccident pointed out, adding this dependency globally could affect all users. For instance, those with an existing MLIR Python environment might encounter errors after updating their code if we presume the installation of this ml_dtypes package.

[stellaraccident]

I think adding it to the project requirements with a note about it being optional is fine, as then the upstream CI will test it. But the code path itself should be optional. This API gets integrated in a bunch of places, and it is those leaves which specify concrete deps for their case. The local requirements file is just for upstream.

[xurui1995]

I think adding it to the project requirements with a note about it being optional is fine, as then the upstream CI will test it. But the code path itself should be optional. This API gets integrated in a bunch of places, and it is those leaves which specify concrete deps for their case. The local requirements file is just for upstream.

Hi, @stellaraccident thanks for your review.
I'd like to add ml_dtypes in requirements.txt with a note and keep try...except in np_to_memref.py, but I have a question about the new bf16 test case inmlir/test/python/execution_engine.py, after adding ml_dtypes in requirements.txt, should we assume that ml_dtypes is installed by default, or should this test case also be considered as part of the code path and need a try...except?

[stellaraccident]

Try adding the test case without the try...except. In theory, if people/bots are developing on this project, they should have the requirements installed. I can't guarantee that all bots are actually doing that though -- so we will have to see.

[xurui1995]

Try adding the test case without the try...except. In theory, if people/bots are developing on this project, they should have the requirements installed. I can't guarantee that all bots are actually doing that though -- so we will have to see.

@stellaraccident I just pushed a commit for doing that, and then it could not pass the CI. We do have the CI code in https://github.com/llvm/llvm-project/blob/d34be649af1aa849c21a5a0570617c3a89d5f0b8/.ci/monolithic-linux.sh#L40C1-L40C66, is there a way to debug for this issue?

[xurui1995]

after fixing and simplifying the test case, the CI can pass now.

[xurui1995]

@stellaraccident hi could you please help merge this?

[stellaraccident]

Yes. On holiday for the weekend so will do it when back.

[xurui1995]

Yes. On holiday for the weekend so will do it when back.

Thanks a lot. Have a good holiday!

[github-actions]

@xurui1995 Congratulations on having your first Pull Request (PR) merged into the LLVM Project!

Your changes will be combined with recent changes from other authors, then tested
by our build bots. If there is a problem with a build, you may receive a report in an email or a comment on this PR.

Please check whether problems have been caused by your change specifically, as
the builds can include changes from many authors. It is not uncommon for your
change to be included in a build that fails due to someone else's changes, or
infrastructure issues.

How to do this, and the rest of the post-merge process, is covered in detail here.

If your change does cause a problem, it may be reverted, or you can revert it yourself.
This is a normal part of LLVM development. You can fix your changes and open a new PR to merge them again.

If you don't get any reports, no action is required from you. Your changes are working as expected, well done!

[joker-eph]

Sorry, I had to revert because this didn't pass in CI: https://lab.llvm.org/buildbot/#/builders/61/builds/58620

[xurui1995]

It seems that the build bot did not successfully install the lib after updating the requirements.txt

[ftynse]

I don't think buildbots install requirements.txt, somebody will have to go and install stuff manually...

[xurui1995]

I don't think buildbots install requirements.txt, somebody will have to go and install stuff manually...

@joker-eph hi, Could you please help me with this, or could you direct me to someone who can?