[CIR][CIRGen] Support CodeGen for vbase constructors #624
+88,200
−70
Conversation
This file contains 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
….scope Incremental work, test coming soon. This code path isn't exercised just yet.
Silly mistake introduced in previous commit.
This will be used for any calls happening inside try regions. More refactoring. For now it's incremental work, still some mileage to cover before I can introduce a testcase. The current implementation mimics cir.call, pieces are going to change in following commits.
The next step for inline assembly. Sorry, maybe it looks too big on the first glance. And it's kind of hard to extract something well-grained from the code and introduce it as a separate PR, but I try. Actually there is nothing really interesting done here, and the next will (I hope :) ) simplify your review process. 1) In this PR we introduce operand's constraints and the task is to collect them (and maybe transform a little) 2) There are two big functions copy-pasted from the traditional `Codegen` and I doubt they need to be reviewed. 3) We still don't do anything CIR-specific. Basically, we just work with strings in the same way like traditional `Codegen` does. 4) We just iterate over the input and output operands and collect the constraints 5) We still follow to the traditional `CodeGen` and don't do anything new, except a separate function that collects constraints infos in the very beginning of the `buildStmt`. Also, I renamed `AsmDialect` to `AsmFlavor` as you asked in llvm#326
This PR fixes CIR lowering for the next case.
```
void foo() {
struct {
int a;
int b;
} a[1] = {{0,1}};
}
```
Note, we don't create attribute here and lower such const arrays as
values.
When introducing attribute `#cir.int`, the constant type verification is not updated. If a `cir.const` operation produces an integral constant from a `#cir.int` attribute, the integer's type is not verified: ```mlir %1 = cir.const(#cir.int<0> : !cir.int<s, 8>) : !cir.int<u, 8> // Not verified: !cir.int<s, 8> differs from !cir.int<u, 8> ``` The corresponding test is also wrong but fail to be detected. This patch fixes this issue.
This is part 2 of implementing vector types and vector operations in ClangIR, issue llvm#284. Create new operation `cir.vec.insert`, which changes one element of an existing vector object and returns the modified vector object. The input and output vectors are prvalues; this operation does not touch memory. The assembly format and the order of the arguments match that of llvm.insertelement in the LLVM dialect, since the operations have identical semantics. Implement vector element lvalues in class `LValue`, adding member functions `getVectorAddress()`, `getVectorPointer()`, `getVectorIdx()`, and `MakeVectorElt(...)`. The assembly format for operation `cir.vec.extract` was changed to match that of llvm.extractelement in the LLVM dialect, since the operations have identical semantics. These two features, `cir.vec.insert` and vector element lvalues, are used to implement `v[n] = e`, where `v` is a vector. This is a little tricky, because `v[n]` isn't really an lvalue, as its address cannot be taken. The only place it can be used as an lvalue is on the left-hand side of an assignment. Implement unary operators on vector objects (except for logical not on a vector mask, which will be covered in a future commit for boolean vectors). The code for lowering cir.unary for all types, in `CIRUnaryOpLowering::matchAndRewrite`, was largely rewritten. Support for unary `+` on non-vector pointer types was added. (It was already supported and tested in AST->ClangIR CodeGen, but was missing from ClangIR->LLVM Dialect lowering.) Add tests for all binary vector arithmetic operations other than relational operators and shift operators. There were all working after the previous vector types commit, but only addition had beet tested at the time. Co-authored-by: Bruno Cardoso Lopes <[email protected]>
Detaches the representation of the C/C++ `continue` statement into a separate operation. This simplifies mostly lowering and verifications related to `continue` statements, as well as the definition and lowering of the `cir.yield` operation. A few checks regarding region terminators were also removed from the lowering stage, since they are already enforced by MLIR. ghstack-source-id: 1810a48ada88fe7ef5638b0758a2298d9cfbdb8b Pull Request resolved: llvm#394
Same rationale as `cir.continue`, it detaches the representation of the C/C++ `break` statement into a separate operation. This simplifies lowering and verifications related to `break` statements, as well as the definition and lowering of the `cir.yield` operation. ghstack-source-id: 929cf96c3abe51d717c2fa6ca9e0073e42e770c6 Pull Request resolved: llvm#395
This changes the `cir.await` operation to expect a `cir.condition` as the terminator for the ready region. This simplifies the `cir.await` while also simplifying the `cir.yield`. If `cir.condition` holds a true value, then the `cir.await` will continue the coroutine, otherwise, it will suspend its execution. The `cir.condition` op was also updated to allow `cir.await` as its parent operation. ghstack-source-id: 1ebeb2cfbdeff6f289936d16354cba534e093ea7 Pull Request resolved: llvm#396
Instead of having a `cir.yield fallthrough` operation, the default branching behavior of the parent operation is denoted by `cir.yield`. In other words, a `cir.yield` operation in a switch case region represents the default branching behavior of the switch operation, which is a fallthrough. The `cir.yield` operation now represents the default branching behavior of the parent operation's region. For example, in a if-else region, a `cir.yield` operation represents a branch to the exit block. ghstack-source-id: 713c457dfb2228fbdf63ba72dd6396665512bb9d Pull Request resolved: llvm#397
…tcase - Add cir.try_call parsing. - Add block destinations and hookup exception info type. - Properly implement interface methods. Printer is still missing, but coming next.
After some discussions with @sitio-couto, it might be better if we use a simplified version that doesn't take the labels into account just yet. `cir.try_call` should have the same semantics as `cir.break`, in the sense that it needs further expansion when getting rid of structured control flow. Early lowering here would complicate CIR generated code and make it harder to analyse. Further CIR to CIR passes will properly expand this at some point prior to LLVM lowering.
We can now handle more of EHScope::Catch and lay out the skeleton for CIR's version of that, adding tons of asserts for cases not currently handled. As part of this we're able to build the clause list as part of CatchOp based on the handlers, and create allocation for the exception_info type. In the next part (where we currently hit an assert) of this work, the CatchOp will then get its regions populated. Incremental steps into getting basic exceptions to work, not enough for a testcase just yet.
Doesn't do a lot of things compared to LLVM traditional codegen, one more step towards basic exception support. No testcase possible just yet.
- Add an extra CatchOp region to hold fallback (where EH usually resumes or rethrows as part of try/catch). - Emit `cir.resume` on the fallback region. Incremental step into the next assertion, still missing pieces before adding the first testcase.
This commit supports the codegen of wide string literals, including `wchar_t` string literals, `char16_t` string literals, and `char32_t` string literals. I'm not following the proposal in llvm#374. The clang frontend doesn't record the literal string. It only records the encoded code units for wide string literals. So I believe that a dedicated string attribute with an encoding tag as described in llvm#374 may not be that helpful as I thought.
This patch introduces initial support for: ``` pragma omp parallel ``` This patch doesn't add support for any of the `parallel` clauses, including variable privatization; thus, all variables are handled as shared. This PR fixes issue llvm#285.
Adds an interface to generically handle lowering and analysis of loop operations in CIR. It can also perform verification of invariants common to all loop operations. ghstack-source-id: 0e413b14ea063a2b0d75aeaca0af88e547c15277 Pull Request resolved: llvm#405
Leverages the new LoopOpInterface for lowering instead of the LoopOp operation. This is a step towards removing the LoopOp operation. ghstack-source-id: 28c1294833a12669d222a293de76609d2cf19148 Pull Request resolved: llvm#406
Creates a separate C/C++ operation for do-while loops, while keeping the LoopOpInterface to generically handle loops. This simplifies the IR generation and printing/parsing of do-while loops. It also allows us to define it regions in the order that they are executed, which is useful for the lifetime analysis. ghstack-source-id: b4d9517197b8f82ae677dc2684101fe5762b21b7 Pull Request resolved: llvm#407
Creates a separate C/C++ operation for while loops, while keeping the LoopOpInterface to generically handle loops. This simplifies the IR generation and printing/parsing of while loops. ghstack-source-id: 29a6d7530263a4f96dbe6ce3052875831126005d Pull Request resolved: llvm#408
This patch completes the deprecation of the generic `cir.loop` operation by adding a new `cir.for` operation and removing the `cir.loop` op. The new representation removes some bloat and places the regions in order of execution. ghstack-source-id: 886e0dacc632e5809015e2212810d690ef3ec294 Pull Request resolved: llvm#409
…rations More machinery for exceptions. This time around we finally emit a cir.catch and fix the order of emitting operations. This allows a testcase to be added. I also added `CatchParamOp`, which fetches the arguments for the clauses from the !cir.eh_info object. Work coming next: - Dtors. - Use cir.try instead of cir.scope. - Eesume. - Documentation.`
Move it up for visibility, just like the other dialect headers.
1. Add new `cir.vtt.address_point` op for visiting the element of VTT to initialize the virtual pointer. 2. Implement `getVirtualBaseClassOffset` method which provides a virtual offset to adjust to actual virtual pointers in virtual base. 3. Follows the original clang CodeGen scheme for the implementation of most other parts.
Laity000
changed the title
|
Could you review this PR when you have some free time? @bcardosolopes |
|
Looking at it this week! Thanks |
|
@Laity000, one thing you'd need to add: "LLVM" checks as part of the testcase, you can see examples in some other tests (e.g. clang/test/CIR/CodeGen/abstract-cond.c). We also just rebased against upstream, you need to update the PR too! |
|
ping :) |
smeenai
added a commit
to smeenai/clangir
that referenced
this pull request
Sep 4, 2024
This is a straightforward adaption from CodeGen. I checked the uses of the Delegating arg that's passed in various places, and it only appears to be used by virtual inheritance, which should be handled by llvm#624.
bcardosolopes
pushed a commit
that referenced
this pull request
Sep 9, 2024
This is a straightforward adaption from CodeGen. I checked the uses of the Delegating arg that's passed in various places, and it only appears to be used by virtual inheritance, which should be handled by #624.
|
I haven't read through all of the patch yet, but one initial thought is that VTTs are an Itanium ABI-specific concept (the Microsoft ABI doesn't use constructor vtables). Are we okay encoding something ABI-specific as a ClangIR operation, or should those be more generic? |
|
@smeenai yes, if someone is interested in MS ABI at some point, then we can decide some other solution: either conceptualize something more generic, or add specific operations for MS behavior - trying to be generic now might be misleading given we are not gonna be exercising any use case we know. |
Closed
Hugobros3
pushed a commit
to shady-gang/clangir
that referenced
this pull request
Oct 2, 2024
This is a straightforward adaption from CodeGen. I checked the uses of the Delegating arg that's passed in various places, and it only appears to be used by virtual inheritance, which should be handled by llvm#624.
smeenai
added a commit
to smeenai/clangir
that referenced
this pull request
Oct 9, 2024
This is a straightforward adaption from CodeGen. I checked the uses of the Delegating arg that's passed in various places, and it only appears to be used by virtual inheritance, which should be handled by llvm#624.
smeenai
added a commit
to smeenai/clangir
that referenced
this pull request
Oct 9, 2024
This is a straightforward adaption from CodeGen. I checked the uses of the Delegating arg that's passed in various places, and it only appears to be used by virtual inheritance, which should be handled by llvm#624.
|
I just cherry-picked this and been fixing some stuff, should land it directly and I'll update this PR with more info. |
keryell
pushed a commit
to keryell/clangir
that referenced
this pull request
Oct 19, 2024
This is a straightforward adaption from CodeGen. I checked the uses of the Delegating arg that's passed in various places, and it only appears to be used by virtual inheritance, which should be handled by llvm#624.
lanza
pushed a commit
that referenced
this pull request
Nov 5, 2024
This is a straightforward adaption from CodeGen. I checked the uses of the Delegating arg that's passed in various places, and it only appears to be used by virtual inheritance, which should be handled by #624.
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.
cir.vtt.address_pointop for visiting the element of VTT to initialize the virtual pointer.getVirtualBaseClassOffsetmethod which provides a virtual offset to adjust to the actual virtual pointer in virtual base.