[PATCH] llvm: Enable MLIR support

[PATCH] llvm: Enable MLIR support

[Luca Fancellu]

Enable the MLIR LLVM project in the clang folder so the compiler
flow can use MLIR and TOSA APIs that are not provided by a plain
LLVM build.

Add a patch that fix the install targets for mlir-src-sharder
and mlir-irdl-to-cpp.

Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>
---
 ...l-helper-tools-used-by-CMake-exports.patch | 59 +++++++++++++++++
 meta/recipes-devtools/clang/common.inc        |  1 +
 meta/recipes-devtools/clang/llvm-mlir_git.bb  | 66 +++++++++++++++++++
 3 files changed, 126 insertions(+)
 create mode 100644 meta/recipes-devtools/clang/clang/0042-MLIR-Install-helper-tools-used-by-CMake-exports.patch
 create mode 100644 meta/recipes-devtools/clang/llvm-mlir_git.bb

diff --git a/meta/recipes-devtools/clang/clang/0042-MLIR-Install-helper-tools-used-by-CMake-exports.patch b/meta/recipes-devtools/clang/clang/0042-MLIR-Install-helper-tools-used-by-CMake-exports.patch
new file mode 100644
index 000000000000..6079e61c9cc2
--- /dev/null
+++ b/meta/recipes-devtools/clang/clang/0042-MLIR-Install-helper-tools-used-by-CMake-exports.patch
@@ -0,0 +1,59 @@
+From e5f6551510eb2adb1fffe9564965101e05ca9720 Mon Sep 17 00:00:00 2001
+From: Momchil Velikov <momchil.velikov@arm.com>
+Date: Fri, 19 Jun 2026 18:00:51 +0000
+Subject: [PATCH] [MLIR] Install missing standalone helper tools
+
+Standalone MLIR installs CMake package files that can reference helper
+executables needed by downstream builds. Most helper tools already have
+install paths available through existing LLVM tool and utility install
+options, but mlir-src-sharder does not pass an install destination to
+add_tablegen and mlir-irdl-to-cpp does not define an install rule.
+
+Install those two missing helpers.
+
+Co-Authored-by: Luca Fancellu <luca.fancellu@arm.com>
+Upstream-Status: Submitted [https://github.com/llvm/llvm-project/pull/205066]
+
+Backported to oe-core version of clang.
+
+Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>
+---
+ mlir/tools/mlir-irdl-to-cpp/CMakeLists.txt | 11 +++++++++++
+ mlir/tools/mlir-src-sharder/CMakeLists.txt |  2 ++
+ 2 files changed, 13 insertions(+)
+
+diff --git a/mlir/tools/mlir-irdl-to-cpp/CMakeLists.txt b/mlir/tools/mlir-irdl-to-cpp/CMakeLists.txt
+index 27a7e22db7d7..5b69b364c6b3 100644
+--- a/mlir/tools/mlir-irdl-to-cpp/CMakeLists.txt
++++ b/mlir/tools/mlir-irdl-to-cpp/CMakeLists.txt
+@@ -7,3 +7,14 @@ mlir_target_link_libraries(mlir-irdl-to-cpp
+   )
+ 
+ setup_host_tool(mlir-irdl-to-cpp MLIR_IRDL_TO_CPP MLIR_IRDL_TO_CPP_EXE MLIR_IRDL_TO_CPP_TARGET)
++
++if(NOT LLVM_INSTALL_TOOLCHAIN_ONLY)
++  install(TARGETS mlir-irdl-to-cpp
++          RUNTIME DESTINATION "${MLIR_TOOLS_INSTALL_DIR}"
++          COMPONENT mlir-irdl-to-cpp)
++  if(NOT LLVM_ENABLE_IDE)
++    add_llvm_install_targets(install-mlir-irdl-to-cpp
++                             DEPENDS mlir-irdl-to-cpp
++                             COMPONENT mlir-irdl-to-cpp)
++  endif()
++endif()
+diff --git a/mlir/tools/mlir-src-sharder/CMakeLists.txt b/mlir/tools/mlir-src-sharder/CMakeLists.txt
+index 6f98bd15fc18..07ad45e52592 100644
+--- a/mlir/tools/mlir-src-sharder/CMakeLists.txt
++++ b/mlir/tools/mlir-src-sharder/CMakeLists.txt
+@@ -2,6 +2,8 @@ set(LLVM_LINK_COMPONENTS Support)
+ set(LIBS MLIRSupport)
+ 
+ add_tablegen(mlir-src-sharder MLIR_SRC_SHARDER
++  DESTINATION "${MLIR_TOOLS_INSTALL_DIR}"
++  EXPORT MLIR
+   mlir-src-sharder.cpp
+ 
+   DEPENDS
+-- 
+2.34.1
+
diff --git a/meta/recipes-devtools/clang/common.inc b/meta/recipes-devtools/clang/common.inc
index 441ea099a9e1..96c6f1217176 100644
--- a/meta/recipes-devtools/clang/common.inc
+++ b/meta/recipes-devtools/clang/common.inc
@@ -60,6 +60,7 @@ SRC_URI = "\
     file://0039-Rename-UNUSED-and-UNKNOWN-elements-of-OffloadArch-enum.patch \
     file://0040-libcxxabi-declare-__gnu_unwind_frame-in-cxa_personal.patch \
     file://0041-Consolidate-and-fix-sysroot-based-compiler-rt-search.patch \
+    file://0042-MLIR-Install-helper-tools-used-by-CMake-exports.patch \
 "
 # Fallback to no-PIE if not set
 GCCPIE ??= ""
diff --git a/meta/recipes-devtools/clang/llvm-mlir_git.bb b/meta/recipes-devtools/clang/llvm-mlir_git.bb
new file mode 100644
index 000000000000..f9f52a236489
--- /dev/null
+++ b/meta/recipes-devtools/clang/llvm-mlir_git.bb
@@ -0,0 +1,66 @@
+#
+# SPDX-FileCopyrightText: <text>Copyright 2026 Arm Limited and/or its
+# affiliates <open-source-office@arm.com></text>
+#
+# SPDX-License-Identifier: MIT
+
+SUMMARY = "MLIR compiler infrastructure"
+DESCRIPTION = "MLIR is a reusable and extensible compiler infrastructure from the LLVM project."
+HOMEPAGE = "https://mlir.llvm.org"
+SECTION = "devel"
+
+require common-clang.inc
+require common-source.inc
+
+LICENSE = "Apache-2.0-with-LLVM-exception"
+LIC_FILES_CHKSUM = "file://mlir/LICENSE.TXT;md5=7ef1911355f6e321fa0d7971689b7a67"
+
+inherit cmake pkgconfig
+
+DEPENDS = "llvm"
+DEPENDS:append:class-target = " llvm-mlir-native"
+DEPENDS:append:class-nativesdk = " llvm-mlir-native"
+
+OECMAKE_SOURCEPATH = "${S}/mlir"
+
+PACKAGECONFIG ??= "shared-libs"
+PACKAGECONFIG[shared-libs] = "\
+    -DLLVM_BUILD_LLVM_DYLIB=ON -DLLVM_LINK_LLVM_DYLIB=ON -DMLIR_LINK_MLIR_DYLIB=ON, \
+    -DLLVM_BUILD_LLVM_DYLIB=OFF -DLLVM_LINK_LLVM_DYLIB=OFF -DMLIR_LINK_MLIR_DYLIB=OFF, \
+"
+
+MLIR_NATIVE_TOOLS_OECMAKE = "\
+    -DLLVM_NATIVE_TOOL_DIR=${STAGING_BINDIR_NATIVE} \
+    -DMLIR_TABLEGEN=${STAGING_BINDIR_NATIVE}/mlir-tblgen \
+    -DMLIR_PDLL_TABLEGEN=${STAGING_BINDIR_NATIVE}/mlir-pdll \
+    -DMLIR_IRDL_TO_CPP=${STAGING_BINDIR_NATIVE}/mlir-irdl-to-cpp \
+    -DMLIR_LINALG_ODS_YAML_GEN=${STAGING_BINDIR_NATIVE}/mlir-linalg-ods-yaml-gen \
+"
+MLIR_NATIVE_TOOLS_OECMAKE:class-native = ""
+
+EXTRA_OECMAKE += "\
+    -DCMAKE_BUILD_TYPE=MinSizeRel \
+    -DLLVM_DIR=${STAGING_LIBDIR}/cmake/llvm \
+    -DLLVM_ENABLE_ASSERTIONS=OFF \
+    -DLLVM_ENABLE_PIC=ON \
+    -DMLIR_ENABLE_BINDINGS_PYTHON=OFF \
+    -DMLIR_INCLUDE_TESTS=OFF \
+    -DMLIR_INCLUDE_INTEGRATION_TESTS=OFF \
+    -DCROSS_TOOLCHAIN_FLAGS_NATIVE='-DCMAKE_TOOLCHAIN_FILE=${WORKDIR}/toolchain-native.cmake' \
+    -DLLVM_BUILD_UTILS=ON \
+    -DLLVM_BUILD_TOOLS=ON \
+    -DLLVM_INSTALL_TOOLCHAIN_ONLY=OFF \
+    ${MLIR_NATIVE_TOOLS_OECMAKE} \
+"
+
+OECMAKE_TARGET_COMPILE:class-native = "all mlir-src-sharder"
+
+PACKAGES =+ "${PN}-tools"
+
+FILES:${PN}-tools += "\
+    ${bindir}/mlir-* \
+    ${bindir}/tblgen-* \
+"
+FILES:${PN}-dev += "${libdir}/objects-*"
+
+BBCLASSEXTEND = "native nativesdk"
-- 
2.34.1

Re: [OE-core] [PATCH] llvm: Enable MLIR support

[Alexander Kanavin]

On Thu, 25 Jun 2026 at 15:31, luca fancellu via lists.openembedded.org
<luca.fancellu=arm.com@lists.openembedded.org> wrote:
>
> Enable the MLIR LLVM project in the clang folder so the compiler
> flow can use MLIR and TOSA APIs that are not provided by a plain
> LLVM build.

This needs a bit more justification. What is 'MLIR', what is 'TOSA'
and why are those things important enough to be provided by oe-core?
The recipe is added, but not used by anything.

Alex

Re: [OE-core] [PATCH] llvm: Enable MLIR support

[Luca Fancellu]

Hi Alex,

> On 25 Jun 2026, at 16:22, Alexander Kanavin <alex.kanavin@gmail.com> wrote:
> 
> On Thu, 25 Jun 2026 at 15:31, luca fancellu via lists.openembedded.org
> <luca.fancellu=arm.com@lists.openembedded.org> wrote:
>> 
>> Enable the MLIR LLVM project in the clang folder so the compiler
>> flow can use MLIR and TOSA APIs that are not provided by a plain
>> LLVM build.
> 
> This needs a bit more justification. What is 'MLIR', what is 'TOSA'
> and why are those things important enough to be provided by oe-core?
> The recipe is added, but not used by anything.

Thanks, that is a fair point. The commit message is too terse and does
not explain why this belongs in oe-core.

MLIR is the LLVM project's multi-level IR compiler infrastructure. It is
used by compiler stacks that need to represent and lower higher-level
programs through multiple abstraction levels before reaching LLVM IR or
target-specific code. TOSA is one of the upstream MLIR dialects: it models
tensor operators used by ML compiler flows, especially when lowering neural
network workloads towards CPU, GPU, DSP or NPU-style targets.

The reason I proposed this in oe-core is that it is part of the same
llvm-project source tree that oe-core already carries for llvm/clang/lld/lldb.
MLIR consumers are tightly coupled to the LLVM/MLIR version and exported CMake
targets. If oe-core does not provide it, downstream layers that need MLIR for
AI/ML compiler flows have to carry their own LLVM/MLIR recipe or build a
private copy, which risks version skew with oe-core's LLVM and duplicates a
large toolchain component.

The recipe is intentionally standalone and not added to the default llvm or
clang build, so existing builds do not pay the MLIR build cost. It is only
built when requested by a layer, image, SDK, or native toolchain component.
The native and nativesdk variants are important because MLIR is commonly used
as build-time compiler infrastructure rather than as a target runtime library.

I agree that having no in-tree consumer makes the patch weaker. One option I
can add is a small meta-selftest consumer recipe that uses CMake
find_package(MLIR CONFIG), links against the exported MLIR targets, and builds
a tiny program using the TOSA dialect. That would not make MLIR part of any
default image, but it would give oe-core coverage that the recipe exports a
usable MLIR SDK/native integration and that the TOSA dialect APIs are available.

If the preference is still that new recipes must have a production oe-core
consumer rather than a selftest consumer, then I will drop this.

Cheers,
Luca

Re: [OE-core] [PATCH] llvm: Enable MLIR support

[Alexander Kanavin]

On Fri, 26 Jun 2026 at 09:39, Luca Fancellu <Luca.Fancellu@arm.com> wrote:

> I agree that having no in-tree consumer makes the patch weaker. One option I
> can add is a small meta-selftest consumer recipe that uses CMake
> find_package(MLIR CONFIG), links against the exported MLIR targets, and builds
> a tiny program using the TOSA dialect. That would not make MLIR part of any
> default image, but it would give oe-core coverage that the recipe exports a
> usable MLIR SDK/native integration and that the TOSA dialect APIs are available.
>
> If the preference is still that new recipes must have a production oe-core
> consumer rather than a selftest consumer, then I will drop this.

Thanks, that all makes sense, and since oe-core adopted clang, it
should be providing all parts of it. Oe-core does not need to have a
'production' consumer, and a synthetic test is fine, so at least it's
possible to know it's not completely broken. You need to extend the
commit message with this information, so it's recorded in git history.

The one part that is missing and that I would like to see is a
'production' usage of this in some other public layer. Is that being
developed somewhere? Presumably you're going to use this recipe for
'real work', can you show it? The more usage you can show, the
stronger the case.

Alex

Re: [OE-core] [PATCH] llvm: Enable MLIR support

[Luca Fancellu]

Hi Alex,

> On 26 Jun 2026, at 15:17, Alexander Kanavin <alex.kanavin@gmail.com> wrote:
> 
> On Fri, 26 Jun 2026 at 09:39, Luca Fancellu <Luca.Fancellu@arm.com> wrote:
> 
>> I agree that having no in-tree consumer makes the patch weaker. One option I
>> can add is a small meta-selftest consumer recipe that uses CMake
>> find_package(MLIR CONFIG), links against the exported MLIR targets, and builds
>> a tiny program using the TOSA dialect. That would not make MLIR part of any
>> default image, but it would give oe-core coverage that the recipe exports a
>> usable MLIR SDK/native integration and that the TOSA dialect APIs are available.
>> 
>> If the preference is still that new recipes must have a production oe-core
>> consumer rather than a selftest consumer, then I will drop this.
> 
> Thanks, that all makes sense, and since oe-core adopted clang, it
> should be providing all parts of it. Oe-core does not need to have a
> 'production' consumer, and a synthetic test is fine, so at least it's
> possible to know it's not completely broken. You need to extend the
> commit message with this information, so it's recorded in git history.
> 
> The one part that is missing and that I would like to see is a
> 'production' usage of this in some other public layer. Is that being
> developed somewhere? Presumably you're going to use this recipe for
> 'real work', can you show it? The more usage you can show, the
> stronger the case.

Thanks, that makes sense.

For v2 I will extend the commit message with the MLIR/TOSA background and
the oe-core rationale: MLIR is part of llvm-project, its consumers are
version-coupled to LLVM/MLIR CMake exports, and carrying it in oe-core avoids
downstream layers having to build or package a private LLVM/MLIR copy that can
drift from oe-core's LLVM.

I will also add a small selftest consumer recipe which uses
find_package(MLIR CONFIG), links against the exported MLIR targets, and builds
a tiny program using the TOSA dialect. That should give oe-core coverage that
the recipe is usable without making MLIR part of any default build.

On the production usage: I cannot point to a public OpenEmbedded/Yocto layer
today. The concrete use case that triggered this work is not public yet, and I
am not aware of another public layer consuming LLVM MLIR at the moment, so I do
not want to overstate that part.

I still think oe-core is the right place for this because it is an optional,
standalone recipe for a component from the same llvm-project source tree that
oe-core already provides. If the lack of a public production consumer makes it
premature, I can hold the patch back until such a consumer is available.
Otherwise I will send a v2 with the expanded commit message and selftest
coverage.

Cheers,
Luca

Re: [OE-core] [PATCH] llvm: Enable MLIR support

[Alexander Kanavin]

On Fri, 26 Jun 2026 at 16:55, Luca Fancellu <Luca.Fancellu@arm.com> wrote:
> On the production usage: I cannot point to a public OpenEmbedded/Yocto layer
> today. The concrete use case that triggered this work is not public yet, and I
> am not aware of another public layer consuming LLVM MLIR at the moment, so I do
> not want to overstate that part.
>
> I still think oe-core is the right place for this because it is an optional,
> standalone recipe for a component from the same llvm-project source tree that
> oe-core already provides. If the lack of a public production consumer makes it
> premature, I can hold the patch back until such a consumer is available.
> Otherwise I will send a v2 with the expanded commit message and selftest
> coverage.

You should send a v2, so it gets a full review. Whether oe-core should
carry something that technically belongs in oe-core, but has no open
source consumers is a question for the openembedded technical steering
committee. My personal take (and I'm not in the TSC) is that the
situation is fundamentally unfair: this pushes the maintenance burden
onto the openembedded community (for example, when this recipe fails
to build or fails to pass its test on clang version bump or other
changes), while the benefits are kept to this proprietary, secretive
project that you're involved in. If/when there's a public consumer,
this would tilt the balance clearly in favour.

Alex

Re: [OE-core] [PATCH] llvm: Enable MLIR support

[Mathieu Dubois-Briand]

On Thu Jun 25, 2026 at 3:31 PM CEST, luca fancellu via lists.openembedded.org wrote:
> Enable the MLIR LLVM project in the clang folder so the compiler
> flow can use MLIR and TOSA APIs that are not provided by a plain
> LLVM build.
>
> Add a patch that fix the install targets for mlir-src-sharder
> and mlir-irdl-to-cpp.
>
> Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>

Hi Luca,

Thanks for your patch.

> +++ b/meta/recipes-devtools/clang/llvm-mlir_git.bb
> @@ -0,0 +1,66 @@
> +#
> +# SPDX-FileCopyrightText: <text>Copyright 2026 Arm Limited and/or its
> +# affiliates <open-source-office@arm.com></text>
> +#
> +# SPDX-License-Identifier: MIT

You will need to add a maintainer line in
meta/conf/distro/include/maintainers.inc for this new recipe.

Thanks,
Mathieu

-- 
Mathieu Dubois-Briand, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [OE-core] [PATCH] llvm: Enable MLIR support

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 2371 bytes --]

On Fri, Jun 26, 2026 at 8:51 AM Alexander Kanavin via lists.openembedded.org
<alex.kanavin=gmail.com@lists.openembedded.org> wrote:

> On Fri, 26 Jun 2026 at 16:55, Luca Fancellu <Luca.Fancellu@arm.com> wrote:
> > On the production usage: I cannot point to a public OpenEmbedded/Yocto
> layer
> > today. The concrete use case that triggered this work is not public yet,
> and I
> > am not aware of another public layer consuming LLVM MLIR at the moment,
> so I do
> > not want to overstate that part.
> >
> > I still think oe-core is the right place for this because it is an
> optional,
> > standalone recipe for a component from the same llvm-project source tree
> that
> > oe-core already provides. If the lack of a public production consumer
> makes it
> > premature, I can hold the patch back until such a consumer is available.
> > Otherwise I will send a v2 with the expanded commit message and selftest
> > coverage.
>
> You should send a v2, so it gets a full review. Whether oe-core should
> carry something that technically belongs in oe-core, but has no open
> source consumers is a question for the openembedded technical steering
> committee. My personal take (and I'm not in the TSC) is that the
> situation is fundamentally unfair: this pushes the maintenance burden
> onto the openembedded community (for example, when this recipe fails
> to build or fails to pass its test on clang version bump or other
> changes), while the benefits are kept to this proprietary, secretive
> project that you're involved in. If/when there's a public consumer,
> this would tilt the balance clearly in favour.
>

This is a reasonable thing, consumers would come in open or proprietary
tools that we might not be aware of. FWIW It will enable OE to build mojo
ML compiler infrastructure, which would be a good demonstration of its need.
Anyone up for meta-mojo ?


>
> Alex
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#239652):
> https://lists.openembedded.org/g/openembedded-core/message/239652
> Mute This Topic: https://lists.openembedded.org/mt/119973309/1997914
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [
> raj.khem@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>

[-- Attachment #2: Type: text/html, Size: 3554 bytes --]