Hi Alex, > On 25 Jun 2026, at 16:22, Alexander Kanavin <[email protected]> wrote: > > On Thu, 25 Jun 2026 at 15:31, luca fancellu via lists.openembedded.org > <[email protected]> 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
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#239612): https://lists.openembedded.org/g/openembedded-core/message/239612 Mute This Topic: https://lists.openembedded.org/mt/119973309/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
