WIP on some CIR → MLIR experiment #1334
Draft
+168,035
−5,245
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 |
Reland previously reverted attempt now that this passes ASANified `ninja check-clang-cir`. Original message: We are missing cleanups all around, more incremental progress towards fixing that. This is supposed to be NFC intended, but we have to start changing some bits in order to properly match cleanup bits in OG. Start tagging places with more MissingFeatures to allow us to incrementally improve the situation.
…#1262) This patch adds support for the following GCC function attributes: - `__attribute__((const))` - `__attribute__((pure))` The side effect information is attached to the call operations during CIRGen. During LLVM lowering, these information is consumed to further emit appropriate LLVM metadata on LLVM call instructions.
…m#1249) C/C++ functions returning void had an explicit !cir.void return type while not having any returned value, which was breaking a lot of MLIR invariants when the CIR dialect is used in a greater context, for example with the inliner. Now, a C/C++ function returning void has no return type and no return values, which does not break the MLIR invariant about the same number of return types and returned values. This change does not keeps the same parsing/pretty-printed syntax as before for compatibility like in llvm#1203 because it requires some new features from the MLIR parser infrastructure itself, which is not great. This uses an optional type for function return type. The default MLIR parser for optional parameters requires an optional anchor we do not have in the syntax, so use a custom FuncType parser to handle the optional return type.
Some passes not declared with TableGen did not have descriptions.
This PR adds a support for for default arguments
…#1283) Corresponding [OG code](https://github.com/llvm/clangir/blob/ef20d053b3d78c9d4c135e2811b303b7e5016d30/clang/lib/CodeGen/CGExprConstant.cpp#L846). [OG generated code here](https://godbolt.org/z/x6q333dMn), one notable diff is we're missing `inrange` which is reported in [issue 886 ](llvm#886). For now, I'm still using GlobalViewAttr to implement it so we can move things fast. But it might be worth considering approach [Comments in issue 258](llvm#258), especially we could incoporate [inrange info](llvm#886) to the attribute suggested there.
This PR adds CIRGen and LLVM lowering support for the following language features related to pointers to data members: - Comparisons between pointers to data members. - Casting from pointers to data members to boolean. - Reinterpret casts between pointers to data members.
This PR updates the `#cir.global_view` attribute and make it accept integer types as its result type.
…vm#1280) Resolves llvm#1266 After change: ```llvm %1 = alloca ptr, i64 1, align 8 store i32 1, ptr @g_arr, align 4 store i32 2, ptr getelementptr (i32, ptr @g_arr, i64 1), align 4 store i32 3, ptr getelementptr (i32, ptr @g_arr, i64 2), align 4 %2 = load i32, ptr @g, align 4 store i32 %2, ptr getelementptr (i32, ptr @g_arr, i64 3), align 4 store ptr getelementptr (i32, ptr getelementptr (i32, ptr @g_arr, i64 3), i64 1), ptr %1, align 8 ```
This does not change anything in practice, work in that direction should come next. We also want this to not affect existing tests to isolate upcoming changes.
This change adds initial support for array new expressions where the array size is constant and the element does not require a cookie.
- After abba01a, 'is' and 'get' interfaces are deprecated even though not removed yet. However, it causes warnings and triggers build failures if that warnings are treated as errors.
Currently, the following code snippet fails with a crash during CodeGen
```
class C {
public:
~C();
void operator=(C);
};
void d() {
C a, b;
a = b;
}
```
with error:
```
mlir::Block* clang::CIRGen::CIRGenFunction::getEHResumeBlock(bool, cir::TryOp): Assertion `tryOp && "expected available cir.try"' failed.
```
in CIRGenCleanup [these
lines](https://github.com/llvm/clangir/blob/204c03efbe898c9f64e477937d869767fdfb1310/clang/lib/CIR/CodeGen/CIRGenCleanup.cpp#L615C1-L617C6)
don't check if there is a TryOp when at the end of the scope chain
before
[getEHResumeBlock](https://github.com/llvm/clangir/blob/204c03efbe898c9f64e477937d869767fdfb1310/clang/lib/CIR/CodeGen/CIRGenException.cpp#L764)
is called causing the crash, because it contains an assertion.
This PR fixes this and adds a simple test for a case like this.
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 |
lanza
force-pushed
the
main
branch
2 times, most recently
from
d2c4ab8 to
8f89224
Compare
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.