Replaces separate x86vector named intrinsic operations with direct calls
to LLVM intrinsic functions.
This rework reduces the number of named ops leaving only high-level MLIR
equivalents of whole intrinsic classes e.g., variants of AVX512 dot on
BF16 inputs. Dialect conversion applies LLVM intrinsic name mangling
further simplifying lowering logic.
The separate conversion step translating x86vector intrinsics into LLVM
IR is also eliminated. Instead, this step is now performed by the
existing llvm dialect infrastructure.
RFC:
https://discourse.llvm.org/t/rfc-simplify-x86-intrinsic-generation/85581
MacOS platforms using mlir-runner in lit tests consistently hit the
following error:
```
# .---command stderr------------
# | JIT session error: Symbols not found: [ __mlir_ciface_printMemrefI32 ]
# | Error: Failed to materialize symbols: { (main, { __mlir_printMemrefI32, ... }) }
# `-----------------------------
```
https://github.com/google/heir/issues/1521#issuecomment-2751303404
confirms the issue is fixed by using `alwayslink` on these two targets,
and I confirmed on a separate Apple M1 (OSX version Sequoia 15.3.2.).
I'm not an expert on the mlir runner internals, but given the
mlir-runner is purely for testing, and alwayslink at worst adds some
overhead by not removing symbols, it seems low risk.
TOSA MLIR profile-based validation is designed to identify the
profile/extension requirements for each operation in TOSA MLIR graph,
ensuring that TOSA operators conform to the profiles and extensions
enabled by the target implementation.
The available profiles/extensions are reflected in the availability
property attached to each TOSA operator in the dialect. The design of
availability, the profile/extension classes, and their interface, is
inspired by the SPIRV implementation.
This patch includes the following changes:
- Introduces profile and extension knowledge within the dialect and
establishes an interface to query this information.
- Implements profile-based validation logic in the pass.
- Adds a TargetEnv class that represents the capabilities enabled in the
target implementation, such as profiles, extensions, and levels.
- Adds a set of tests to ensure that profile and extension requirements
are properly attached to the operations and that validation correctly
verifies the requirements of a given operation against the target
implementation.
Move LinalgInterfaces.cpp from LinalgInterfaces to LinalgDialect target.
This allows TensorDialect to use header-only RelayoutOpInterface without introducing a hidden dependency on LinalgDialect (producing an `no-allow-shlib-undefined` error if a target depends on TensorDialect but not LinalgDialect).
Also reverts d64f177a2f because it's no longer needed.