WIP on some CIR → MLIR experiment #1334
Draft
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
✅ With the latest revision this PR passed the C/C++ code formatter. |
keryell
force-pushed
the
mlir-aie-version
branch
2 times, most recently
from
6d3dee3 to
b5a29d4
Compare
keryell
force-pushed
the
mlir-aie-version
branch
2 times, most recently
from
80f1134 to
28e0d6b
Compare
This was referenced Feb 22, 2025
keryell
force-pushed
the
mlir-aie-version
branch
3 times, most recently
from
e79112e to
f0632d5
Compare
keryell
force-pushed
the
mlir-aie-version
branch
from
f0632d5 to
00c9c59
Compare
|
TODO: integrate support for arbitrary |
Export this function so it can be used by other projects.
This allows the inliner to work with the CIR dialect.
This allows injecting some dialects and patterns to the cir::ConvertCIRToMLIRPass lowering pass.
This allows injecting some dialects and patterns to the cir::direct::ConvertCIRToLLVMPass lowering pass.
Forward the data layout to the type converter. This is not a current solution since it is not possible for now to have a memref of tuple in MLIR yet.
No operation yet. Just lowering to memref<!named_tuple.named_tuple<>> for now.
WIP memref cast operation for NamedTuple hack.
The `named_tuple.cast` operation converts a memref of `named_tuple` to a 1D
memref of `i8` of the same size to emulate later the struct element access.
Example:
%0 = named_tuple.cast %alloca_0 : memref<!named_tuple.named_tuple<"s", [i32, i32]>> to memref<8xi8> loc(#loc6)
Emulate the member access through memory for now.
Do not go through a memref of memref.
Arrays in C/C++ have usually a reference semantics and can be lowered to memref. But when inside a class/struct/union, arrays hav a value semantics and can be lowered as tensor.
Remove a shortcut preventing some level of memref recursion.
Export cir::lowerArrayType() so a CIR client can use this function to lower some !cir.array.
Just keep the lowering inside a named_type as a tensor. This fix cir.alloca lowering issue.
Split completely the !cir.array lowering, like in struct/class/union, from any reference with memref construction. Rationalize the approach inside convertToReferenceType() instead of ad-hoc cases all-over the place. Fix a test which seems to have been wrong from the beginning.
Handle pointer strides in quite more contexts. Make the code type-safe with the right memref layouts matching the reinterpret_cast details to avoid tripping the verifiers. This problem was hidden in the past due to the fact that the load/store lowering discarded some intermediate incorrect code for the tested simple cases.
It was removed upstream from mlir::DataLayoutEntryInterface. See: - llvm/llvm-project#128772 - llvm/llvm-project#128754
cir::StructType has been renamed to cir::RecordType.
keryell
force-pushed
the
mlir-aie-version
branch
from
00c9c59 to
39b162f
Compare
The -emit-mlir syntax has changed and now requires the kind of MLIR to be specified.
|
The 3 failing tests are because there is an issue in |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Experiment with some CIR → MLIR std dialect lowering.
Not supposed to be merged but useful to get some CI feedback.
This is related to the long running PR Xilinx/mlir-aie#1913
Work-in-progress on CIR→MLIR lowering
This is a huge work-in-progress version adding new features used by
aie++C++ programming model, such asbetter support for lowering through MLIR standard dialects.
What is experimented here:
tensorfor value semantics (for example instructs) and
memreffor reference semantics (all the other uses);tupleandthen introducing a new
named_tupledialect;memrefflattening and castingcasting;
broader framework;
The output of this new lowering flow has not been tested yet followed by the
MLIR std→LLVMIR.
An issue with
tensoris that we cannot have random types in atensorand there is no trait to change this behavior.An alternative design could be to rely on some MLIR std→LLVMIR→MLIR std
back-and-forth traveling in the same module to have some parts of the LLVMIR
dialect to implement some missing features like it is done in the
Polygeist project.
See #1219 for discussions about CIR → MLIR lowering issues.