[CIR] Cleanup cir.scopes with a single cir.yield operation #482

This diverges from the original codegen by tracking all members of a union, instead of just the largest one. This is necessary to support type-checking at the MLIR level when accessing union members. It also preserves more information about the source code, which might be useful. Fixes llvm#224 ghstack-source-id: 8a975426d077a66c49f050741d7362da3c102fed Pull Request resolved: llvm#229

Converts a union to a struct containing only its largest element. GetMemberOp for unions is lowered as bitcasts instead of GEPs, since union members share the same address space. ghstack-source-id: 744ac312675b8f3225ccc459fcd09474bcfcfe81 Pull Request resolved: llvm#230

…lvm#241) Similar with the previous ctor support, I'm bringing up the dtor support for global var initialization. This change only contains the CIR early codegen work. The upcoming lowering prepare work will be in a separate change.

This change adds lowering support for global variable definition with destructor. For example: ``` cir.global "private" internal @_ZL8__ioinit = ctor : !ty_22Init22 { %0 = cir.get_global @_ZL8__ioinit : cir.ptr <!ty_22Init22> %1 = cir.const(#true) : !cir.bool cir.call @_ZN4InitC1Eb(%0, %1) : (!cir.ptr<!ty_22Init22>, !cir.bool) -> () } dtor { %0 = cir.get_global @_ZL8__ioinit : cir.ptr <!ty_22Init22> cir.call @_ZN4InitD1Ev(%0) : (!cir.ptr<!ty_22Init22>) -> () } ``` is now lowered to ``` cir.func internal private @__cxx_global_var_init() { %0 = cir.get_global @_ZL8__ioinit : cir.ptr <!ty_22Init22> %1 = cir.const(#true) : !cir.bool cir.call @_ZN4InitC1Eb(%0, %1) : (!cir.ptr<!ty_22Init22>, !cir.bool) -> () %2 = cir.get_global @_ZL8__ioinit : cir.ptr <!ty_22Init22> %3 = cir.get_global @_ZN4InitD1Ev : cir.ptr <!cir.func<!void (!cir.ptr<!ty_22Init22>)>> %4 = cir.cast(bitcast, %3 : !cir.ptr<!cir.func<!void (!cir.ptr<!ty_22Init22>)>>), !cir.ptr<!cir.func<!void (!cir.ptr<!void>)>> %5 = cir.cast(bitcast, %2 : !cir.ptr<!ty_22Init22>), !cir.ptr<!void> %6 = cir.get_global @__dso_handle : cir.ptr <i8> cir.call @__cxa_atexit(%4, %5, %6) : (!cir.ptr<!cir.func<!void (!cir.ptr<!void>)>>, !cir.ptr<!void>, !cir.ptr<i8>) -> () cir.return } ``` Note that instead calling the destructor in the global initializer function, a registration with `__cxa_atexit` is done instead so that the destructor will be called right before the program is shut down.

Add two new CIR ops: cir.alloc_exception and cir.throw, they are higher level representations for their __cxa_* counterparts. Add CIRGen for a simple `throw <expr>` example, which requires using the above added operations. Rethrow mechanism (plain `throw`) is still NYI. For LLVM lowering: LoweringPrepare work needs to be done next, breaking these ops back to functions calls.

Add an assert while we don't handle the available externally.

Add lots of necessary boilerplate for personality functions, catch block tracking and building catch scope stack. We enter the try but no catching handling yet. New paths all guarded with asserts, therefore NFC.

In order to support exceptions, skeleton for unwind detection.

…call attributes soon

Populate regions and basic blocks for handling try-catch! No testcases just yet, new path guarded with unreachable, so effectively this is NFC.

…lvm#242).

This PR removes the method `hasBooleanRepresentation` as was discussed in [PR#233](llvm#233) Briefly, the `cir.bool` has the same representation in memory and after load. The LLVM IR differs, that's why the check is there, in the origin `CodeGen`. Also, in order to trigger the path and make the implementation to be conform with the original `CodeGen`, there are changes in the `CIRGenExprScalar`: call the common `buildFromLValue` instead of manaul `load` creation. Also, a couple of tests for the bool load/store added

…n. (llvm#253) Introducing `cir.ConstPtrAttr` to represent arbitrary absolute pointer value initializations. Also incorporating previous `cir.nullptr` effort into this work.

Following discussion in llvm#237 this adds support for `fabs` builtins which are used extensively in llvm-test-suite.

Temporary workaround until we patch the codegen for record types.

This patch brings up the basic support for C++ virtual inheritance. VTT (virtual table table) now can be laid out as expected for simple program with single virtual inheritance. RTTI support is on the way. This patch does not include LLVM lowering support.

This PR introduces bitfelds support. This now works: ``` #include <stdio.h> typedef struct { int a1 : 4; int a2 : 28; int a3 : 16; int a4 : 3; int a5 : 17; int a6 : 25; } A; void init(A* a) { a->a1 = 1; a->a2 = 321; a->a3 = 15; a->a4 = -2; a->a5 = -123; a->a6 = 1234; } void print(A* a) { printf("%d %d %d %d %d %d\n", a->a1, a->a2, a->a3, a->a4, a->a5, a->a6 ); } int main() { A a; init(&a); print(&a); return 0; } ``` the output is: `1 321 15 -2 -123 1234`

…vm#233)" Breaks ninja check-clang-cir This reverts commit 471e568.

- Introduces `CIR/Interfaces/ASTAttrInterfaces` which model API of clang AST nodes, but allows to plugin custom attribute, making `CIR` dialect AST independent. - Extends hierarchy of `DeclAttr`s to model `Decl` attributes more faithfully. - Notably all `CIRASTAttr`s are now created uniformly using `makeAstDeclAttr` which builds corresponding Attribute based on `clang::Decl`.

…lvm#263) There is a bug in the code generation: the field index for the `GetMemberOp` is taken from the `FieldDecl`, with no respect to the record layout. One of the manifestation of the bug is the wrong index generated for a field in a derived class that does not take into the account the instance of the base class (that has index 0). You can take a look at the example in `test/CIR/CodeGen/derived-to-base.cpp`, i.e. the current test is not the correct one ``` // CHECK-DAG: !ty_22C23A3ALayer22 = !cir.struct<class "C2::Layer" {!ty_22C13A3ALayer22, !cir.ptr<!ty_22C222> // CHECK-DAG: !ty_22C33A3ALayer22 = !cir.struct<struct "C3::Layer" {!ty_22C23A3ALayer22 // CHECK: cir.func @_ZN2C35Layer10InitializeEv // CHECK: cir.scope { // CHECK: %2 = cir.base_class_addr(%1 : cir.ptr <!ty_22C33A3ALayer22>) -> cir.ptr <!ty_22C23A3ALayer22> // CHECK: %3 = cir.get_member %2[0] {name = "m_C1"} : !cir.ptr<!ty_22C23A3ALayer22> -> !cir.ptr<!cir.ptr<!ty_22C222>> ``` As one can see, the result (of ptr type to `!ty_22C222` ) must have the index `1` in the corresponded struct `ty_22C23A3ALayer22`. Basically the same is done in the `clang/CodeGen/CGExpr.cpp`, so we don't invent something new here. Note, this fix doesn't affect anything related to the usage of `buildPreserveStructAccess` where the `field->getFieldIndex()` is used.

This PR adds MLIR lowering of `cir.scope`. I also notice that the MLIR unit tests still uses old integer types. I will fix those in a separate PR.

Recent work on exceptions broke an internal testcase, free the path back while I work on a holistic solution.

We've integrated this functionality into the main clang-tidy and clangd tools and no longer have a purpose for it. We only kept around to maintain support for internal tooling built upon it. So remove it here.

Here is the promised patch that adds proper type conversion to CIR -> MLIR conversion. I tried to keep the changes minimum but the existing implementation doesn't use `TypeConverter`. This should not have any functional changes except for one tiny fix that registers the `cf` dialect, which should allow `goto.mlir` to pass. Happy to break the PR into two if requested.

…lvm#268) This is an updated PR for [PR llvm#233](llvm#233) with some fixes explained in [PR llvm#261](llvm#261) which now can be safely closed. First of all, let me introduce how do the bitfields looks like in CIR. For the struct `S` defined as following: ``` typedef struct { int a : 4; int b : 27; int c : 17; int d : 2; int e : 15; unsigned f; } S; ``` the CIR type is `!ty_22S22 = !cir.struct<struct "S" {!u32i, !u32i, !u16i, !u32i} #cir.record.decl.ast>` where all the bitfields are packed in the first three storages. Also, the next bugs was fixed: - type mismatch - index out of bounds - single bitfield of size < 8 The cases covered with tests.

llvm#270) This is a minor fix similar to the one introduced in llvm#263. Basically, all calls to the `buildLValueForFieldInitialization` are even with the origin codegen `emitLValueForFieldInitialization` calls, i.e. the field index is calculated from the record layout, but not from the decl `field->getFieldIndex()`. Added just one test, because looks like we need to implement some `NYI` features first to test another places e.g. in `CIRGenExprAgg.cpp`, though I could miss something. Anyway, given the original codegen doesn't use `getFieldIndex` in these places, we also should not. All the remaining usages of `getFieldIndex` are ok.

Updates the lowering pass to use only opaque pointers. This essentially involves updating the type converter to drop pointee types and explicitly defining the types loaded/stored/GEPed by LLVM operations. The reasons for this are twofold: - LLVM dialect is currently transitioning to deprecate typed pointers, allowing only opaque pointers. The sooner we transition the fewer changes we will have to make. - Opaque pointers greatly simplify lowering self-references, since all self-references in records are wrapped in a pointer.

The wrong element type was being passed to LLVM's GEP op, generating an invalid IR. Tests were also updated to properly validate the `llvm.getelementptr` element type. Fixes llvm#272

This PR adds `cir.brcond` lowering, which more or less follows the one in LLVM dialect lowering.

This is a suggestion to relax the existing verification even more than we did it in PR llvm#257. Here we also skip verification if a field on the given index is also of incomplete type - and we can not compare it with the result type of the operation. Now the next code fails with type mismatch error: ``` typedef struct Node { struct Node* next; } NodeStru; void foo(NodeStru* a) { a->next = 0; } ``` because the result type is kind of full and the type of field is not (for the reasons discussed in llvm#256). Basically, the problem is in the `GetMemberOp` result type generated as following (via `CIRGenTypes::convertType`) `!cir.ptr<!cir.struct<struct "Node" {!cir.ptr<!cir.struct<struct "Node" incomplete #cir.record.decl.ast>>} #cir.record.decl.ast>>` where the field type at index differs from the record type - compare with `!cir.ptr<!cir.struct<struct "Node" incomplete #cir.record.decl.ast>>` We just slightly relax the previous solution in llvm#257 - and the compilation won't fail in the case of recursive types. Well, if there are some other thoughts?

Just a trivial fix that enables declaration of local structs. Basically, there it's a copy-pasta from the original `CodeGen`, without debug info handling. Co-authored-by: Bruno Cardoso Lopes <bcardosolopes@users.noreply.github.com>

This PR handles globals initializations for c++ code for the case when a global is inited from a function call or another global.

Traditional Clang's codegen generates IDs for anonymous records (e.g. "struct.anon.1") and ensures that they are unique. This patch does the same for CIRGen, which, until now, would just identify any anonymous record as "anon". This will be required to support mutable structs uniquely identified by their names.

Rename `typeName` to just `name`, also use `StringAttr`'s nullability to identify if the record is identified or anonymous. Unnamed structs are also no longer aliased, as they have no unique name to be used in the alias.

This patch adds RTTI support for C++ virtual inheritance. This patch does not include LLVM lowering support.

Lowering Vtable and RTTI globals. Also lowering AddressPoint. based on llvm#259

The `body` attribute is used to identify if a struct type has a body or not. In other words, it separates complete from incomplete structs. For this reason, the `body` attribute was renamed to `incomplete`, matching its keyword in the CIR language.

MLIR's attributes are inherently nullable, so there is no need to use std::optional to represent a nullable attribute. This patch removes std::optional from StructType's ast attribute to simplify its usage.

…ong and untested CastKind::floating path

In the CIR CodeGen function `ScalarExprEmitter::buildScalarCast`, implement conversions from bool to an integral type. This was inadvertently left out in earlier changes. Reorganize the code in the function to be more clear, with better assertion failure messages when encountering an unimplemented construct. This is a partial fix for issue llvm#290

As discussed in llvm#279, we split `CIRGenBuilder` in two parts, which make some of the helpers usable outside of the `CodeGen` part. Basically, I placed casts and binary operations into a separate class, `CIRBaseBuilder`. Later, it can be extended with another helpers. But right now an idea to have a state less builder as a base one.

A silly fix for code like ``` *(char *)0 = 0; ```

) Currently, different specializations of a template will generate distinct types with the same name. To properly differentiate each specialization, this patch includes the template arguments in the name of the type. This will be required to support mutable structs uniquely identified by their names.

Instead of using a single builder for every possible StructType, we now have three builders: identified complete, identified incomplete, and anonymous struct types. This allows us to enforce correctness and to explicitly show the intent when creating a StructType. This patch also adds support for anonymous structs type aliases. When a StructType has no name, it will generate a `ty_anon_<kind>` alias. Conflicts are automatically resolved by MLIR.

There are instances of CIR where anonymous structs are generated as identified structs with an empty name. This patch Adds a verifier for StructType, which ensures structs have a non-empty name. This will be required for properly uniqueing mutable CIR structs.

Essentially, this patch redefines the CIR StructType manually instead of using the autogenerated definition from tablegen. This is the first step to make StructType mutable, as this feature is not yet supported by tablegen. It's mostly a copy of the tablegen definition, with a few notable differences: - A few embellishments are added to make the code more dev-friendly - Addition of a CIRTypesDetails.h file to keep custom storage definitions - The CIR_AnyCIRType constraint is removed, as it is not used and must be defined in C++ to ensure StructType is a part of it. ghstack-source-id: 5f706dc0a61a4a2ed6e2f20ab0937b1a42bfa9cc Pull Request resolved: llvm#302

This allows a named StructType to be mutated after it has been created, if it is identified and incomplete. The motivation for this is to improve the codegen of CIR in certain scenarios where an incomplete type is used and later completed. These usually leave the IR in an inconsistent state, where there are two records types with the same identifier but different definitions (one complete the other incomplete). For example: ```c++ struct Node { Node *next; }; void test(struct Node n) {} ``` Generates: ```mlir !temp_struct = !cir.struct<struct "Node" incomplete> !full_struct = !cir.struct<struct "Node" {!cir.ptr<!temp_struct>}> ``` To generate the `Node` struct type, its members must be created first. However, the `next` member is a recursive reference, so it can only be completed after its parent. This generates a temporary incomplete definition of the `Node` type that remains in the code even after the type to which it refers is completed. As a consequence, accessing the `next` member of a `Node` value fetches the old incomplete version of the type which affects CIR's type-checking capabilities. This patch ensures that, once the parent is fully visited, the `next` member can be completed in place, automatically updating any references to it at a low cost. To represent recursive types, the StructType now is equipped with self-references. These are represented by a `cir.struct` type with just the name of the parent struct that it refers to. The same snippet of code will not generate the following CIR IR: ```mlir !full_struct = !cir.struct<struct "Node" {!cir.ptr<!cir.struct<struct "Node">>}> ``` Summary of the changes made: - Named records are now uniquely identified by their name. An attempt to create a new record with the same will fail. - Anonymous records are uniquely identified by members and other relevant attributes. - StructType has a new `mutate` method that allows it to be mutated after it has been created. Each type can only be mutated if it is identified and incomplete, rendering further changes impossible. - When building a new name StructType, the builder will try to first create, then complete the type, ensuring that: - Inexistent types are created - Existing incomplete types are completed - Existing complete types with matching attributes are reused - Existing complete types with different attributes raise errors - StructType now uses the CyclicParser/Printer guard to avoid infinite recursion and identify when it should print/parse a self-reference. ghstack-source-id: a6d4f650515cbf2d7f6e27d45aae6f768ba44f92 Pull Request resolved: llvm#303

Matrix types are already checked for in `buildScalarConversion`, so they don't need to be checked for again in `buildScalarCast`. Not having to worry about matrix types means the `Element` local variables are no longer necessary. Remove duplicate code by having a variable to store the `CastKind`, and have only one call to `Builder.create<CastOp>`. There are no test changes, because this is refactoring only. There should be no functional changes.

The PR fixes a var initialization with explicit cast.

Add a new entry to enum `CastKind`, `bool_to_float`, since none of the existing enum values adequately covered that conversion. Add code to code gen, CIR validation, LLVM lowering, and the cast test to cover this conversion. Fix ClangIR issue llvm#290

Fix a couple typos in the validation failure messages for scalar casts

Conversions from an integer to a pointer are implemented in CIR code gen as an integral conversion to uintptr_t followed by the integral-to-pointer conversion. Conversions from bool to pointer were following the same code path. But bool-to-int is a different CastKind than int-to-int in CIR, and CIR was failing validation. Fix the integer to pointer conversion code to correctly handle a source type of bool. (A conversion from bool to pointer makes no sense and should never happen in the real world. But it is legal due to bool being sort of an integral type. So we need to support it.) Also, in `ScalarExprEmitter::buildScalarConversion` change a couple not-yet-implemented messages about pointer types into assertion failures. Conversions involving pointer types should never go through `ScalarExprEmitter::buildScalarConversion`.

This PR fixes a bug with wrong arguments passed into the call to `buildAnyExpr`. This function has args with default values, hence the bug occurred. All the changes are even with the clang's original codegen. For the reference, the LLVM IR code for `agg-init.cpp::usev()` function looks like the following: ``` define dso_local void @_Z3usev() #0 { entry: %agg.tmp.ensured = alloca %struct.yep_, align 4 %Status = getelementptr inbounds %struct.yep_, ptr %agg.tmp.ensured, i32 0, i32 0 store i32 0, ptr %Status, align 4 %HC = getelementptr inbounds %struct.yep_, ptr %agg.tmp.ensured, i32 0, i32 1 store i32 0, ptr %HC, align 4 ret void } ```

…h-299). (llvm#305) This PR adds proper handling for address offsets in global initializers as e.g. in ``` int val[10]; int *addr = &val[1]; ``` (such offsets are ignored on current trunk). I'm not proud of this patch because it performs an ugly conversion from byte offset, produced by `APValue::getLValueOffset`, to a sequence of CIR indices. Alternative suggestions are welcomed.

This PR adds a support of the function pointers in CIR. From the implementation point of view, we emit an address of a function as a `GlobalViewAttr`.

) Basically that is, the next code should work now ``` typedef struct { int a; int b; } A; ... A a = {0, 0}; ```

Since recursive types were perfectly fixed, we can safely remove the assert that prevented functons types generation for the case of incomplete types. The test is added - just to show that everything is ok for such kind of functions.

@sitio-couto

I think it's time to claim that CIR supports recursive types (many thanks to llvm#303 and to @sitio-couto :) ) And we can bring back the `get_member` verification back, with no checks for incomplete types. What do you think? And we can close llvm#256 as well

Just a minor fix with for incomplete arrays + minor refactoring

…vm#334)

While here toggle LexicalScopeGuard's visibility, to be consistent..

This adds more support for automatic variable destruction, which is long due. There are more bits to come in following patches but this enables the bulk mechanism. - Bake running cleanup functionality from scopes into LexicalScopeContext - This is closer to traditional LLVM codegen, LexicalScopeContext now inherits from RunCleanupsScope. - Merge LexicalScopeContext and LexicalScopeGuard into one LexicalScope - Proper implement dtor for lexicalScope and fwd ForceCleanup - Add testcase

Fixes llvm#337

@bcardosolopes

This is a followup PR to comment llvm#305 (comment) by @bcardosolopes

ConstPtrAttrs with numbers instead of the `null` keyword were not parsed correctly.

Two fixes were applied: - A couple of `lowerCirAttrAsValue` visitors were fixed as one of the arguments was missing the const qualifier on the type converter. To avoid this problem, the const qualifier was moved to before the type. - In the type converter, `cir.struct`s were wrongly identified by their name's length, now, they are identified by their name's existence.

This patch fixes the agg-init2.cpp test by doing two things: - Updating the `VisitCXXConstructExpr` to return a zero attribute initializer for trivial zero-initialized objects. - Forcing the `buildAutoVarInit` method to use ctor calls on temporary object expressions even if the object can be constant-initialized.

Replaces the usage of builtin integers in the CIR code and removes the dynamic dimension from `memref`s lowered from `!cir.ptr` types.

This PR adds a support of copies of aggregated data types via assignment.

As we discussed in llvm#233, there is a desire to have CIR operations for bit fields set/get access and do all the stuff in the `LoweringPrepare`. There is one thing I want to discuss, that's why the PR is marked as a draft now. Looks like I have to introduce some redundant helpers for all these `or` and `shift` operations: while we were in the `CodeGen` area, we used `CIRGenBuilder` and we could easily extend it. I bet we don't want to depend from `CodeGen` in the `LoweringPrepare`. Once it's true. what is a good place for all this common things? As an idea, we could introduce one more layer for builder, with no state involved - just helpers and nothing else. But again, what is a good place for it from your point of view?

Instead of ignoring global view access with zero offset, we should properly dereference the global type to prevent type-matching errors. This patch also fixes other two issues: - An extra index was wrongly added to the global view access. E.g. for an access like `a[0]` would generate a GV with 2 zero indexes. The indexes, however, do not take the pointer wrapping the global type into account. - When assigning the address of a complete type to an incomplete one the complete type would override the incomplete destination type, causing inconsistencies during CodeGen. For example, given `int a[3];` and `int (*ptr_a)[] = &a;`, despite `ptr_a`, in CIR it would be considered complete. Fixes llvm#329

Closes llvm#288 The action mirrors https://github.com/llvm/llvm-project/blob/main/.github/workflows/clang-tests.yml with a few minor differences: - it is not restricted to: `github.repository_owner == 'llvm'` - it triggers on pull requests and pushes to `main` instead of `release` branches I suggest adding branch protection rule to require tests to pass for each pull request: `Settings -> Branches -> Add branch protection rule -> Require status checks to pass before merging`

This allows some dtors code (like in dtors-scopes.cpp) to work and run on macOS

The `shouldPrintTerm` and `checkBlockTerminator` were replaced in favor of `omitRegionTerm` and `ensureRegionTerm` respectively. The first is essentially the same method but simplified. The latter was refactored to do only two things: check if the terminator omission of a region is valid and, if so, insert the omitted terminator into the region. The simplifications mostly leverage the fact that we only omit empty yield values in a single-block region. ghstack-source-id: 7b943719ca0fb4ac2d1d29775d7545787c23bcbf Pull Request resolved: llvm#321

This simplifies and modularizes the assembly format for ScopeOp by using the Tablegen assembly description and a new custom printer/parser that handles regions with omitted terminators. It also fixes an issue where the parser would not correctly handle `cir.scopes` with a return value. ghstack-source-id: c5b9be705113c21117363cb3bd78e19d133c3fc5 Pull Request resolved: llvm#311

I will break the PR llvm#308 into pieces and submit them one-by-one. The first PR introduce CIR operation and the `buildAsmStmt` function. The latter is the main place for the future changesm and the former was taken directly from MLIR LLVM IR dialect. As a result, there is nothing really interesting happen here, but now we can at least emit cir for an empty inline assembler. And as a first step

This PR adds dynamic stack allocation into `AllocaOp` that will be useful in future - currently I work on variable length array support. So I start to make tiny PRs in advance) No changes in tests needed, I tried to make the changes as smooth as possible, so no existing `AllocaOp` usages need to be changed.

) This PR fixes a couple of corner cases connected with the `YieldOp` lowering in loops. Previously, in llvm#211 we introduced `lowerNestedBreakContinue` but we didn't check that `YieldOp` may belong to the same region, i.e. it is not nested, e.g. ``` while(1) { break; } ``` Hence the error `op already replaced`. Next, we fix `yield` lowering for `ifOp` and `switchOp` but didn't cover `scopeOp`, and the same error occurred. This PR fixes this as well. I added two tests - with no checks actually, just to make sure no more crashes happen. fixes llvm#324

Among other long term things, in the short term this will be used to map some higher level library calls into CIR operations.

It's not used just yet, and the ast was removed from printing given we don't have a serialization story anyways, so it's less aggressive with existing tests.

This will be tested soon by some idiom recognition code.

Organize things a bit while here.

- Identify such calls and produce a remark. Next step is to map this to a CIR operation representing std::find, which should come next. - Add new `-fclangir-idiom-recognizer=` option, used to control remark options for now.

This is going to be used to raise `cir.call`s to `std::find(...)` into `cir.std.find`.

Also implement lowering back to `std::call` before lowering to LLVM.

…lvm#353) This PR fixes a global vars lowering with a funciton ptr field. Previously, the next code caused fail in the `foo` lowering: ``` static void myfun(int a) {} static struct { void (*func)(int flag); } const Handlers[] = { {myfun}, {myfun}, {myfun} }; void foo(int i, int flag) { Handlers[i].func(flag); } ```

This is the first part of implementing vector types and vector operations in ClangIR, issue llvm#284. This is enough to compile this test program. I haven't tried to do anything beyond that yet. ``` typedef int int4 __attribute__((vector_size(16))); int main(int argc, char** argv) { int4 a = { 1, argc, argc + 1, 4 }; int4 b = { 5, argc + 2, argc + 3, 8 }; int4 c = a + b; return c[1]; } ``` This change includes: * Fixed-sized vector types which are parameterized on the element type and the number of elements. For example, `!cir.vector<s32i x 4>`. (No scalable vector types yet; those will come later.) * New operation `cir.vec` which creates an object of a vector type with the given operands. * New operation `cir.vec_elem` which extracts an element from a vector. (The array subscript operation doesn't work here because the result is an rvalue, not an lvalue.) * Basic binary arithmetic operations on vector types, though only addition has been tested. There are no unary operators, comparison operators, casts, or shuffle operations yet. Those will all come later.

…vm#356) This PR adds a support for the multi-block case statements. Previously, the code example below caused crash in cir verification Lowering to the `llvm` dialect is pretty straightforward: the same logic as before is applied to all the region's blocks with no successors, i.e. we no longer think a case/default region contains only one block. The `CodeGen` part is a little bit tricky. Previously, any sub-statement of `case` or`default`, that was not any of them (i.e. neither `case` nor `default`) was processed with an insertion guard, meaning that the next sub-statement in the same clause was inserted again in the same block as the first one. It would be fine, once sub-statement didn't generate any blocks as well. For instance, ``` void foo(int a) { switch (a) { case 3: return; break; } } ``` The `return` statement actually emit a new block after, where the unreachable code with `break` should be inserted in. That's why we also need to update `lastCaseBlock` while generating `cir.switch` This is quite frequent bug in `llvm-test-suite`

This contains just the skeleton, but the idea is that this pass is going to contain transformations done on top CIR generated by the C/C++ idiom recognizer.

Specify proper target triples to prevent issues on both Windows and MacOS regarding non-implemented ABI bits.

Only a skeleton for incremental work.

Initial step into modeling iterators in CIR. Right now it only looks at the member functions with .begin/.end function calls, it does not look at the iterator type, has no notion of forward/reverse iterators, nor filters based on the container types - those improvements will come next.

…#355) Before this fix attached test case has been failing due to type mismatch (signed vs unsigned).

Tiny PR, support `-std=gnu89` option This is quite frequent bug in `llvm-test-suite`

This PR "adds" the support of extern vars in function body. Actually, I just erased an assert. Any reason it was there? ``` int foo() { extern int optind; return optind; } ``` This is quite frequent bug in `llvm-test-suite`

This PR adds `cir.stack_save` and `cir.stack_restore` operations.

…m#357) This PR fixes lowering of the next code: ``` void foo(int x, int y) { switch (x) { case 0: if (y) break; break; } } ``` i.e. when some sub statement contains `break` as well. Previously, we did this trick for `loop`: process nested `break`/`continue` statements while `LoopOp` lowering if they don't belong to another `LoopOp` or `SwitchOp`. This is why there is some refactoring here as well, but the idea is stiil the same: we need to process nested operations and emit branches to the proper blocks. This is quite frequent bug in `llvm-test-suite`

This is how both libc++ and libstdc++ implement iterator in std::array, stick to those use cases for now. We could add other variations in the future if there are others around.

- Check whether container is part of std, add a fixed list of available containers (for now only std::array) - Add a getRawDecl method to ASTRecordDeclInterface - Testcases

This was a bit half backed, give it some love.

Inspired by similar work in libc++, pointed to me by Louis Dionne and Nikolas Klauser. This is initial, very conservative and not generalized yet: works for `char`s within a specific version of `std::find`.

…ents. Before this fix conversion of flat offset to GlobalView indices could crash or compute invalid result.

`ScopeOp` may end with `ReturnOp` instead of `YieldOp`, that is not expected now. This PR fix this. The reduced example is: ``` int foo() { { return 0; } } ``` This is quite frequent bug in `llvm-test-suite`

This reverts commit bbaa147.

One more step towards variable length array support. This PR adds one more helper for the `alloca` instruction and re-use the existing ones. The reason is the following: right now there are two possible ways to insert alloca: either to a function entry block or to the given block after all the existing alloca instructions. But for VLA support we need to insert alloca anywhere, right after an array's size becomes known. Thus, we add one more parameter with the default value - insertion point. Also, we don't want copy-paste the code, and reuse the existing helpers, but it may be a little bit confusing to read.

This PR adds `cir.ternary` lowering. There are two approaches to lower `cir.ternary` imo: 1. Use `scf.if` op. 2. Use `cf.cond_br` op. I choose `scf.if` because `scf.if` + canonicalization produces `arith.select` whereas `cf.cond_br` requires scf lifting. In many ways `scf.if` is more high-level and closer to `cir.ternary`. A separate `cir.yield` lowering is required since we cannot directly replace `cir.yield` in the ternary op lowering -- the yield operands may still be illegal and doing so produces `builtin.unrealized_cast` ops. I couldn't figured out a way to solve this issue without adding a separate lowering pattern. Please let me know if you know a way to solve this issue.

This PR fixes the next case ``` typedef struct { } A; A create() { A a; return a; } void foo() { A a; a = create(); } ``` i.e. when a struct is assigned to a function call result

@gitoleg

…vmgh-352) (llvm#363) The error manifested in code like ``` int a[16]; int *const p = a; void foo() { p[0]; } ``` It's one the most frequent errors in current llvm-test-suite. I've added the test to globals.cir which is currently XFAILed, I think @gitoleg will fix it soon. Co-authored-by: Bruno Cardoso Lopes <bcardosolopes@users.noreply.github.com>

This PR addresses llvm#248 . Currently string literals are always lowered to a `cir.const_array` attribute even if the string literal only contains null bytes. This patch make the CodeGen emits `cir.zero` for these string literals.

Currently, codegen of lvalue comma expression would crash: ```cpp int &foo1(); int &foo2(); void c1() { int &x = (foo1(), foo2()); // CRASH } ``` This simple patch fixes this issue.

This PR addresses llvm#90. It introduces a new type constraint `CIR_AnyType` which allows CIR types and MLIR floating-point types. Present `AnyType` constraints are replaced with the new `CIR_AnyType` constraint.

Arrays can be first declared without a known bound, and then defined with a known bound. For example: ```cpp extern int data[]; int test() { return data[1]; } int data[3] {1, 2, 3}; ``` Currently `clangir` crashes on generating CIR for this case. This is due to the type of the `data` definition being different from its declaration. This patch adds support for such a case.

…vm#381)

Breaks the pass into smaller more manageable rewrites.

… the files (llvm#390) Fixes llvm#345

…IdiomRecognizer. (llvm#389) Some tests started failing under `-DLLVM_USE_SANITIZER=Address` due to trivial use-after-free errors.

Like SCF's `scf.condition`, the `cir.condition` simplifies codegen of loop conditions by removing the need of a contitional branch. It takes a single boolean operand which, if true, executes the body region, otherwise exits the loop. This also simplifies lowering and the dialect it self. A new constraint is now enforced on `cir.loops`: the condition region must terminate with a `cir.condition` operation. A few tests were removed as they became redundant, and others where simplified. The merge-cleanups pass no longer simplifies compile-time constant conditions, as the condition body terminator is no longer allowed to be terminated with a `cir.yield`. To circumvent this, a proper folder should be implemented to fold constant conditions, but this was left as future work. Co-authored-by: Bruno Cardoso Lopes <bcardosolopes@users.noreply.github.com>

Once the LexicalScope goes out of scope, its cleanup process will also check if a return was set to be yielded, and, if so, generate the yield with the respective value. ghstack-source-id: 9305d2ba5631840937721755358a774dc9e08b90 Pull Request resolved: llvm#312

Instead of returning a boolean indicating whether the statement was handled, returns the ReturnExpr of the statement if there is one. It also adds some extra bookkeeping to ensure that the result is returned when needed. This allows for better support of GCC's `ExprStmt` extension. The logical result was not used: it was handled but it would never fail. Any errors within builders should likely be handled with asserts and unreachables since they imply a programmer's error in the code. ghstack-source-id: 2319cf3f12e56374a52aaafa4304e74de3ee6453 Pull Request resolved: llvm#313

Adds support for GCC statement expressions return values as well as StmtExpr LValue emissions. To simplify the lowering process, the scope return value is not used. Instead, a temporary allocation is created on the parent scope where the return value is stored. For classes, a second scope is created around this temporary allocation to ensure any destructors are called. This does not implement the full semantics of statement expressions. ghstack-source-id: 64e03fc3df45975590ddbcab44959c2b49601101 Pull Request resolved: llvm#314

Incrementally design out support for try/catch and relationship with calls. This introduces an exception information type, which is will be returned somehow by throwing calls.

This reverts commit 55c03f8

….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 <bcardosolopes@users.noreply.github.com>

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.

@sitio-couto

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.`

This is currently missing and Debug builds are failing without it.

ghstack-source-id: 855519648a4bf2dced501f96e6de1b9b164d85ad Pull Request resolved: llvm#424

… dep

ghstack-source-id: 0706d6bb81b5b8eefb04146719b4443aedb29ab1 Pull Request resolved: llvm#427

…ircular dep

One more step towards completing try/catch.

…rface This is prep work for introducing cir.try_call inside cir.try scopes.

One more incremental step towards try/catch: properly use cir.try_call instead of regular cir.call when within a cir.try region.

) This patch adds a new `volatile` tag to the following operations to distinguish volatile loads and stores from normal loads and stores: - `cir.load` - `cir.store` - `cir.get_bitfield` - `cir.set_bitfield` Besides, this patch also updates the CodeGen and LLVMIR lowering code to start emitting CIR and LLVMIR operations with volatile flag.

This is part 3 of implementing vector types and vector operations in ClangIR, issue llvm#284. Create new operation `cir.vec.cmp` which implements the relational comparison operators (`== != < > <= >=`) on vector types. A new operation was created rather than reusing `cir.cmp` because the result is a vector of a signed intergral type, not a `bool`. Add CodeGen and Lowering tests for vector comparisons. Fix the floating-point comparison predicate when lowering to LLVM. To handle NaN values correctly, the comparisons need to be ordered rather than unordered. (Except for `!=`, which needs to be unordered.) For example, "ueq" was changed to "oeq".

Compilation of the following test ``` void foo6(A* a1) { A a2 = (*a1); } ``` fails with. ``` NYI UNREACHABLE executed at /home/huawei/cir/repo/llvm-project/clang/lib/CIR/CodeGen/CIRGenExprAgg.cpp:175! ``` Commit adds required visitor and fixes the issue.

In the original codegen a new type is created for the base class, while in CIR we were rewriting the type being processed (due tp misused pointers). This PR fix this, and also makes CIR codegen even with the original one.

This is a first PR for variable length array support. There are one (or more :) ) ahead. Basically, we already did lot's of preliminary job in order to land VLA in CIR in llvm#367 llvm#346 llvm#340. So now we add initial VLA support itself. Most of the changes are taken from the original codegen, so there is nothing to be scary of) I added just one test, and basically that's all we can test right now. Later, I will add more, from the original codegen tests.

Support \_\_extension\_\_ keyword in CIRGen

Support for BoolAttr in isNullValue

This PR adds support for section("$name") attribute

Support missing zero initialization of Bools

) Compiling the given c-code ``` void foo() { int i [2][1] = { { 1 }, { 0 } }; long int li[2][1] = { { 1 }, { 0 } }; float fl[2][1] = { { 1 }, { 0 } }; double d [2][1] = { { 1 }, { 0 } }; } ``` leads to compilation error ``` unknown element in ConstArrayAttr UNREACHABLE executed at /home/huawei/cir/repo/van/llvm-project/clang/lib/CIR/Lowering/DirectToLLVM/LowerToLLVM.cpp:951! ``` PR implements conversion the cir.zero attr to dense constant and fixed this error.

This PR introduces CIR CodeGen support for `dynamic_cast`. The full feature set of `dynamic_cast` is not fully implemented in this PR as it's already pretty large. This PR only include support for downcasting and sidecasting a pointer or reference. `dynamic_cast<void *>` is not yet implemented.

Initial support for the following builtins: ``` __builtin_expect __builtin_expect_with_probability __builtin_unpredictable ``` This PR supports codegen for this builtins on "-O0" compilation pipeline.

Support for ConditionalOperator inside the if condition stmt

This patch adds CIRGen for downcasting a pointer to the complete object through `dynamic_cast<void *>`. Together with llvm#426 , the full functionality of `dynamic_cast` should be supported in CIRGen after this PR merges.

This PR adds support for constant arrays with trailing zeros. The original `CodeGen` does the following: once a constant array contain trailing zeros, a struct with two members is generated: initialized elements and `zeroinitializer` for the remaining part. And depending on some conditions, `memset` or `memcpy` are emitted. In the latter case a global const array is created. Well, we may go this way, but it requires us to implement [features](https://github.com/llvm/clangir/blob/main/clang/lib/CIR/CodeGen/CIRGenDecl.cpp#L182) that are not implemented yet. Another option is to add one more parameter to the `constArrayAttr` and utilize it during the lowering. So far I chose this way, but if you have any doubts, we can discuss here. So we just emit constant array as usually and once there are trailing zeros, lower this arrray (i.e. an attribute) as a value. I added a couple of tests and will add more, once we agree on the approach. So far I marked the PR as a draft one.

…nters (llvm#400) This also adds a missing check whether the pointer returned from `memchr` is null and changes the result to `last` in that case.

Emit the false-branch of the consteval if statement, if any.

Originally, the location associated with a function is checked to be an `mlir::FileLineColLoc` before the function is lowered to an LLVMIR FuncOp. However, runtime function declarations do not have such locations. This patch further allows `mlir::UnknownLoc` to be associated with a function.

@gv

This PR adds a support for const structs with bitfields. Now only global structs are supported, the support of the local ones can be added more or less easily - there is one ugly thing need to be done though) So .. what is all about. First of all - as usually, I'm sorry for the big PR. But it's hard to break it down to peaces. The good news is that in the same time it's a copy-pasta from the original codegen, no surprises here. Basically, the most hard place to read is `ConstantAggregateBuilder::addBits` copied with minimum of changes. The main problem - and frankly speaking I have no idea why it's done this way in the original codegen - is that the data layout is different for such structures, I mean literally another type is used. For instance, the code: ``` struct T { int X : 15; int Y : 6; unsigned Z : 9; int W; }; struct T GV = { 1, 5, 256, -1}; ``` is represented in LLVM IR (with no CIR enabled) as: ``` %struct.T = type { i32, i32 } %struct.Inner = type { i8, i32 } @gv = dso_local global { i8, i8, i8, i8, i32 } ... ``` i.e. the global var `GV` is looks like a struct of single bytes (up to the last field, which is not a btfield). And my guess is that we want to have the same behavior in CIR. So we do. The main problem is that we have to treat the same data differently - and this is why one additional `bitcast` is needed when we create a global var. Actually, there was a comment there - and I really wonder where it came from. But anyways, I don't really like this and don't see any good workaround here. Well, maybe we may add a kind of map in order to store the correspondence between types and do a bitcast more wisely. The same is true for the const structs with bitfields defined locally.

The minimal bug repro: ``` #include <stdbool.h> #include <stdint.h> void bar() { bool x = true; uint8_t y = (uint8_t)x; } ``` Fails on verification stage: ``` loc("repro.c":5:24): error: integer width of the output type is smaller or equal to the integer width of the input type fatal error: error in backend: The pass manager failed to lower CIR to LLVMIR dialect! ``` The problem is that in some cases lowering from CIR emits the invalid zext operation. PR fixes this issue by emitting the llvm.bitcast instead of llvm.zext in such cases.

…tchOp

The change is taken from original codegen.

The issue is that the CIR codegen assumes that function pointer is always result of cir.load op. But it isn't true because the funcion pointer may be result of other operations (f.e cir.call).

This PR adds support for global compound literals. The implementation is almost the same as in original codegen. But the original codegen can reuse the value of emitted compound literal global variable in case then the init expression of new variable and this variable are the same. It's easy to implement this feature. But I can't find any test-case then this feature will be applied. So I decided to ignore this optimization opportunity to avoid mistakes.

Here is the next step in VLA support. Basically, these changes handle different expressions, like `int (*a[5])[n]` or `sizeof(a[n])`. I took tests from the original `codegen` - they don't check anything, just verify we don't fail. There is still an issue with a proper cleanup - there are cases when `stack_save` doesn't dominate a corresponded `stack_restore`. For example in the next example: ``` void test(unsigned x) { while (1) { char a[x]; if (x > 5) break; ++x; } } ``` Look like `break` here doesn't lead to `stack_restore`. But I would say this is less related to VLA, though probably I need to fix this as well.

This PR fixes the issue connected with folding a simple boolean expresion pattern (f.e. `0 && RHS = 0`). The problem is that the scalar expression emitter always creates a `cir.bool` attribute as a result of expression. But in some cases the result expression should be a `cir.int` attr.

… start/end functionality

The change is taken from the original llvm codegen.

Originally those are only used for debug info generation, so get a bit more specific on what's missing here.

When replacing the no-proto functions with it's real definition, codegen assumes that only `cir.call` operation may use the replaced function. Such behaviour leads to compilation error because of the `cir.get_global` op can also use the function to get pointer to function. This PR adds handle the case with `cir.get_global` operation and fixes the issue.

…RAII

This PR adds missing case to lowerCirAttrAsValue.

…r.try The final destination here is to support cir.try_calls that are not within a `try {}` statement in C++. This only affect untested paths that will assert a bit later than before, testcase coming soon.

@bar

The second part of the job started in llvm#412 , now about local structures. As it was mentioned previously, sometimes the layout for structures with bit fields inited with constants differ from the originally created in `CIRRecordLayoutBuilder` and it cause `storeOp` verification fail due to different structure type was used to allocation. This PR fix it. An example: ``` typedef struct { int a : 4; int b : 5; int c; } D; void bar () { D d = {1,2,3}; } ``` Well, I can't say I'm proud of these changes - it seems like a type safety violation, but looks like it's the best we can do here. The original codegen doesn't have this problem at all, there is just a `memcpy` there, I provide LLVM IR just for reference: ``` %struct.D = type { i16, i32 } @__const.bar.d = private unnamed_addr constant { i8, i8, i32 } { i8 33, i8 0, i32 3 }, align 4 ; Function Attrs: noinline nounwind optnone uwtable define dso_local void @bar() #0 { entry: %d = alloca %struct.D, align 4 call void @llvm.memcpy.p0.p0.i64(ptr align 4 %d, ptr align 4 @__const.bar.d, i64 8, i1 false) ret void } ```

In llvm#426 we confirmed that CIR needs a `cir.unreachable` operation to mark unreachable program points [(discussion)](llvm#426 (comment)). This PR adds it.

This PR adds support for evaluating constants in member exprs. The change is taken from original codegen.

- Add it to functions but not yet on calls. - Add more skeleton for tagging function attributes. - Testcases One more incremental step towards cir.try_call outside cir.try scopes.

The next step in inline-assembly support: we add instruction operands! Nothing interesting, just some copy-pasta from the `codegen` with some sort of simplifications for now. Well, I'm not sure `functional-type` is the best way to print operands though it's used in mlir's `InlineAsmOp`. But anyways, maybe you have a better idea. There are two or three steps ahead, so we are not that far from being able to run something!

One more tiny step! This a tiny PR that adds clobbers to constraint string. Note, that `~{dirflag},~{fpsr},~{flags}` is a [X86](https://github.com/llvm/clangir/blob/main/clang/lib/Basic/Targets/X86.h#L281) dependent clobbers. Basically, the next things remain: - lowering - store the results of the `cir.asm`

…operation

Expected behavior is that scope blocks with only a single yield op are cleaned up.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[CIR] Cleanup cir.scopes with a single cir.yield operation #482

[CIR] Cleanup cir.scopes with a single cir.yield operation #482

Commits on Jan 29, 2024

Commits on Jan 30, 2024

Commits on Jan 31, 2024

Commits on Feb 2, 2024

Commits on Feb 3, 2024

Commits on Feb 4, 2024

Commits on Feb 5, 2024

Commits on Feb 6, 2024

Commits on Feb 7, 2024

Commits on Feb 8, 2024

Commits on Feb 9, 2024

Commits on Feb 10, 2024

Commits on Feb 12, 2024

Commits on Feb 13, 2024

Commits on Feb 14, 2024

Commits on Feb 15, 2024

Commits on Feb 16, 2024

Commits on Feb 24, 2024

Commits on Mar 13, 2024