Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP on some CIR → MLIR experiment #1334

Draft
wants to merge 20 commits into
base: main
Choose a base branch
from

Conversation

keryell
Copy link
Collaborator

@keryell keryell commented Feb 11, 2025

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 as
better support for lowering through MLIR standard dialects.

What is experimented here:

  • adding new features to CIR→MLIR lowering;
  • cleaner lowering C/C++arrays as tensor for value semantics (for example in
    structs) and memref for reference semantics (all the other uses);
  • fixing array support and allocation;
  • allowing pointer to array or struct;
  • adding support for class/struct/union by first experimenting with tuple and
    then introducing a new named_tuple dialect;
  • implementation of more types of C/C++ casts;
  • support struct member access through some memref flattening and casting
    casting;
  • fixing a lot of verification bugs which are triggered when using ClangIR in a
    broader framework;
  • enabling in-lining interface to CIR dialect;
  • exposing some API to use ClangIR from a broader framework.

The output of this new lowering flow has not been tested yet followed by the
MLIR std→LLVMIR.

An issue with tensor is that we cannot have random types in a tensor and 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.

Copy link

github-actions bot commented Feb 11, 2025

✅ With the latest revision this PR passed the C/C++ code formatter.

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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant