[CIR][CIRGen] Add support for global named registers #741

…lvm#501) This PR adds the LLVMIR lowering support for CIR bit operations. For `cir.bit.clz`, `cir.bit.ctz`, and `cir.bit.popcount`, they can be lowered directly to LLVM intrinsic calls to `@llvm.ctlz`, `@llvm.cttz`, and `@llvm.ctpop`, respectively. For the other three bit operations, namely `cir.bit.clrsb`, `cir.bit.ffs`, and `cir.bit.parity`, they are lowered to a sequence of LLVM IR instructions that implements their functionalities. This lowering scheme is also used by the original clang CodeGen.

CIRGenFunction::buildFromMemory can handle the `cir.bool` values. So we no longer need to emit the `NIY` error here.

This is the next step in inline assembly support and it's more like a service PR and mostly dedicated to the in/out argument types. Also, operand attributes are added and it's the last change in the `cir.asm` operation afaik. But I would wait untill the next PR, which will contain more examples and maybe will help us to get more readable format for the operation. Note, that we have to add an attribute for each operand - because the lowering of the llvm dialect to LLVM IR iterates over them in the same order. The next PR will be last one (so far) in the series of PRs dedicated to the inline assembly support. It will add storing of the results.

Three small changes, all cleanup or refactoring in nature. 1. Fix the assemblyFormat for all the vector operations in the ClangIR dialect so that vector types appear in ClangIR as `!cir.vector<type x n>` instead of as just `<type x n>`. When I first created the vector ops, I forgot to use `qualified` as necessary when writing out types. This change fixes that. There is no change in behavior, but there is a change to the text version of ClangIR, which required changing the ClangIR expected results and ClangIR inputs in the tests. 2. Create a new `cir.vec.splat` operation and use that for "vector splat", i.e. a conversion from a scalar to a vector. A "vector splat" conversion had been implemented with `cir.vec.create` before. This change results in different ClangIR and different LLVM IR, which again required updating the tests, but no noticeable change in compiler behavior. 3. Create an `IntegerVector` type constraint, which requires that the given type be a vector whose element type is an integer. It can be any integral type, and the vector can be of any size. Use the new type constraint in the definition of `cir.vec.ternary`, whose condition operand must be an `IntegerVector`. Remove the integral type check from `VecTernaryOp::verify`, since doing the check there is now redundant. The only possibly visible change is to the text of an error message when validation of `cir.vec.ternary` fails. The expected output of a validation test was updated with the new message.

This PR intends to fix some problems with packed structures support, so the llvm#473 will work. Basically, the main problem for the packed structures support is an absence of arbitrary sized integers in CIR. Well, one workaround is to use `mlir::IntegerType` for that, but it's kind of wrong way (please correct me if I'm wrong). Another way is to introduce this type in CIR. So far I suggest this way: instead of arbitrary sized integers we will create an array of bytes for bitfield storages whenever they doesn't fit into the CIR `IntType`. Well, the original codegen creates storages with alignment 8 - so it can be `i24` storage type for instance. Previously, we just created storages that could be represented as CIR `IntType`: 8, 16, 32, 64. And it was working before I came up with a necessity to support packed structures. At first glance it's not a problem - just add `determinePacked` method from the original codegen and that's it. But it turned out that this method _infers_ the fact if a structure is packed or not. It doesn't use the AST attribute for that as one could think - it works with offsets and alignments of fields. Thus, we either need to invent our own way to determine packed structures (which is error prone and maybe not doable at all) or try to use the existing one. Also, we go closer to the original lllvm's data layout in this case. 1) I had to move the lowering details from the `LoweringPrepare` to the `LowerToLLVM`, because it's not possible to do a `load` from the array of bytes to the integer type - and it's ok in llvm dialect. Thus, all the math operations can be expressed without any problems. Basically the most of the diff you see is because of the changes in the lowering. The remaining part is more or less easy to read. 2) There are minor changes in `CIRRecordLayoutBuilder` - as described above, we use may generate an array of bytes as a storage. 3) Some cosmetic changes in `CIRGenExpr` - since we don't want to infer the storage type again and just use the one stored in the `CIRGenBitFieldInfo`. 4) Helpers are introduced in the lowering - but nothing hard - just shifts and logical ops. 5) I removed `bitfield-ops` test - because now the test cases covered there are all in `bitfields.c` and `bitfields.cpp` . So ... This is still a suggestion, though I believe it's a good one. So you are welcome to discuss, suggest another ways to solve the problem and etc.

Still missing lowering support, which will come next.

This doesn't change existing functionality, for existing crashes related to atomics we just hit asserts a bit further now, but no support added just yet. Next set of commits will introduce functionlity with testcases.

Just like previous commit, add more infra pieces, still NFC since all relevant testcases hit asserts, just a bit deeper.

This PR adds a support for packed structures. Basically, now both `pragma pack(...)` and `__attribute__((aligned(...)))` should work. The only problem is that `getAlignment` is not a total one - I fix only a couple of issues I faced with - for struct types and arrays.

PR adds support for initialization of unions. The change is copy-pasted from the original CodeGen.

This PR adds support for `__builtin_prefetch`. CIRGen of this builtin emits the new 'cir.prefetch' opcode. Then `cir.prefetch` lowers to `llvm.prefetch` intrinsic. Co-authored-by: Bruno Cardoso Lopes <[email protected]>

This PR adds MemRead/MemWrite markers to the `GetBitfieldOp` and `SetBitfieldOp` (as discussed in llvm#487) Also, minor renaming in the `SetBitfieldOp` --------- Co-authored-by: Bruno Cardoso Lopes <[email protected]>

This PR adds support for `__builtin_constant_p`. Implementation introduces the new `cr.is_constant` opcode to it during the codegeneration of builtin. Codegeneration is taken from the original llvm codegen.

This patch adds CIRGen support for the C++20 three-way comparison operator `<=>`. The binary operator is directly lowered to existing CIR operations. Most of the changes are tests.

This change is taken from the original codegen.

…m#517) This PR adds handling of AttributedStmt to support fallthrough attribute.

This change is taken from the original codegen

We start our journey towards `goto` support and this is a first step on this way. There are some discussion in llvm#508 and according to the plan we do the following here: - a new pass called `cir-flatten-cfg` that is a stub now but later will be responsible for the regions inlining. The pass works only if `-emit-flat-cir` is passed in cmd line. Thus, the clang behavior is not changed here from the user's point of view. - The pass will be accomplished with `goto` solver later, so we talk about several passes that are mandatory for the lowering into `llvm` dialect. There are at least two clients of this pass that will be affected: `clang` itself and `cir-opt`, so we need a common point for them: and `populateCIRFlatteningPasses` and `populateCIRToLLVMPasses` guarantee that `CIR` will be in the correct state for all the clients, whatever new passes we will add later.

Implement `__builtin_shufflevector` and `__builtin_convertvector` in ClangIR. This change contributes to the implemention of issue llvm#284. `__builtin_convertvector` is implemented as a cast. LLVM IR uses the same instructions for arithmetic conversions of both individual scalars and entire vectors. So ClangIR does the same. The code for handling conversions, in both CodeGen and Lowering, is cleaned up to correctly handle vector types. To simplify the lowering code and avoid `if (type.isa<VectorType>())` statements everywhere, the utility function `elementTypeIfVector` was added to `LowerToLLVM.cpp`. `__builtin_shufflevector` has two forms, only one of which appears to be documented. The documented form, which takes a variable-sized list of integer constants for the indices, is implemented with the new ClangIR operation `cir.vec.shuffle.ints`. This operation is lowered to the `llvm.shufflevector` op. The undocumented form, which gets the indices from a vector operand, is implemented with the new ClangIR operation `cir.vec.shuffle.vec`. LLVM IR does not have an instruction for this, so it gets lowered to a long series of `llvm.extractelement` and `llvm.insertelement` operations.

This introduces CIRGen and LLVM lowering for the first of a bunch of these atomic operations, incremental work should generelize the current constructs.

This PR adds support for the following intrinsic functions: - `__builtin_bswap{16, 32, 64}` - `_byteswap_{ushort, ulong, uint64}` This PR adds a new `cir.bswap` operation to represent such an intrinsic call. CIRGen and LLVMIR lowering for the new operation is included in this PR.

This is the final commit for issue llvm#284. Vector types other than GNU vector types will be covered by other yet-to-be-created issues. Now that GNU vector types (the ones defined via the vector_size attribute) are implemented, do a final cleanup of the assertions and other checks related to vector types. Remove `UnimplementedFeature::cirVectorType()`. Deal with the remaining calls to that function. When the that is not yet implemented has to do with Arm SVE vectors, the assert was changed to `UnimplementedFeature::scalableVectors()` instead. The assertion was removed in cases where the code correctly handle GNU vector types. While cleaning up the assertion checks, I noticed that BinOp handling of vector types wasn't quite complete. Any special handling for integer or floating-point types wasn't happening when the operands were vector types. To fix this, split `BinOpInfo::Ty` into two fields, `FullType` and `CompType`. `FullType` is the type of the operands. `CompType` is normally the same as `FullType`, but is the element type when `FullType` is a vector type.

…rt fp

Note this is different from __atomic_binop_fetch. See added docs.

…lvm#540) This patch adds the CIRGen for the following builtin functions: - `__builtin_clzg`; - `__builtin_ctzg`; - `__builtin_popcountg`. CIRGen for these three functions are missing in the original PR which introduces CIR bit ops.

Also add skeleton for upcoming dtor support.

@foo

This PR perform flattening for `cir::IfOp` Basically, we just move the code from `LowerToLLVM.cpp` to `FlattenCFG.cpp`. There are several important things though I would like to highlight. 1) Consider the next code from the tests: ``` cir.func @foo(%arg0: !s32i) -> !s32i { %4 = cir.cast(int_to_bool, %arg0 : !s32i), !cir.bool cir.if %4 { %5 = cir.const(#cir.int<1> : !s32i) : !s32i cir.return %5 : !s32i } else { %5 = cir.const(#cir.int<0> : !s32i) : !s32i cir.return %5 : !s32i } cir.return %arg0 : !s32i } ``` The last `cir.return` becomes unreachable after flattening and hence is not reachable in the lowering. So we got the next error: ``` error: 'cir.return' op expects parent op to be one of 'cir.func, cir.scope, cir.if, cir.switch, cir.do, cir.while, cir.for' cir.return %arg0 : !s32i ``` the parent after lowering is `llvm.func`. And this is only the beginning - the more operations will be flatten, the more similar fails will happen. Thus, I added lowering for the unreachable code as well in `LowerToLLVM.cpp`. But may be you have another solution in your mind. 2) Please, pay attention on the flattening pass - I'm not that familiar with `mlir` builders as you are, so may be I'm doing something wrong. The idea was to start flattening from the most nested operations. 3) As you requested in llvm#516, `cir-to-llvm-internal` is renamed to `cir-flat-to-llvm`. The only thing remain undone is related to the following: > Since it would be wrong to run cir-flat-to-llvm without running cir-flatten-cfg, we should make cir-flat-to-llvm pass to require cir-flatten-cfg pass to be run before. And I'm not sure I know how to do it exactly - is there something similar to pass dependencies from LLVM IR? 4) The part of `IfOp` lowering related to elimination of the vain casts for condition branch moved directly to the lowering of `BrCondOp` with some refactoring and guarding. 5) Just note, that now `cir-opt` is able to dump the flat cir as well: `cir-opt -cir-flat-cfg`

This PR adds initial support for the bit-precise integer type `_BitInt(N)`. This type goes into the C23 standard, and has already been supported by clang since 2020, previously known as `_ExtInt(N)`. This PR is quite simple and straight-forward. Basically it leverages the existing `cir.int` type to represent such types. Previously `cir.int` verifies that its width must be a multiple of 8, and this verification has been removed in this PR.

…l addresses

Lowers `cir.objectsize` to `llvm.objectsize`

…t arrays We were lacking handling of trailing zeros for constant arrays.

This PR adds storing of the results of inline assembly operation. This is a **final** step (I hope: ) ) from my side to support inline assembly. There are some features that remains unimplemented, but basic things should work now, For example, we can do addition and get the results - I explicitly added several tests for that, so you can test them in real. For instance, the next program being compiled with CIR should give you 7 as the result: ``` int add(int x, int y) { int a; __asm__("addl %[y], %[x]" : "=r" (a) : [x] "r" (x), [y] "r" (y) ); return a; } int main() { printf("run %d\n", add(3, 4)); return 0; } ``` So, the main thing remains is pretty printing. As I said I added several examples, and may be it will become more clear how to print better. Also, I added several tests from original codegen in order to check that we don't fail. And I can add some checks there as well when we come to better solution on printing.

This reverts commit 87a61f3. It's deleting code it isn't supposed to touch.

This PR is the next step towards goto support and adds flattening for `ScopeOp` and `LoopOpInterface`. Looks like I can't separate this operations and create two PRs, since some errors occur if I do so, e.g. `reference to block defined in another region`. Seems we need to flatten both operations in the same time. Given it's a copy-pasta, I think there is no need to try to make several PRs. I added several tests - just copied them from the lowering part just to demonstrate how it looks like. Note, that changes in `dot.cir` caused by `BrCondOp` updates in the previous PR, when we removed the following casts: ``` %20 = llvm.zext %19 : i1 to i8 %21 = llvm.trunc %20 : i8 to i1 llvm.cond_br %21 ... ```

Minor fix for the case when union fields have different sizes and union is inited with a constant. Example: ``` typedef union { short a; int b; } A; ```

This PR fixes some cases when a program compiled with `-fwrapv` fails with `NYI` . Basically, the default behavior is no overlap: ``` void baz(int x, int y) { int z = x - y; } ``` LLVM IR (no CIR enabled): ``` %sub = sub nsw i32 %0, %1 ``` and with `-fwrapv` : ``` %sub = sub i32 %0, %1 ``` We need something similar in CIR. The only way I see how to implement it is to add a couple of attributes to the `BinOp` to make things even with the llvm dialect. Well, are there any other ideas? --------- Co-authored-by: Bruno Cardoso Lopes <[email protected]>

Catch up with upstream and also update Address.h with one more helper method for `cir::Address`.

…ate call

…on attributes

…match upstream

This PR adds the `cir.dyn_cast` operation for representing `dynamic_cast` in C++. It contains the following contents: - [x] A new `cir.dyn_cast` operation. - [x] ~Two new attributes that will be attached to `cir.dyn_cast` operations:~ - [x] ~`#cir.dyn_cast_info` attributes, which gives general information about a dynamic cast (e.g. the source RTTI pointer, the dest RTTI pointer, etc.)~ - [x] ~`#cir.downcast_info` attribute, which gives even more detailed information about a dynamic cast that is a down-cast. These information will be used when rewriting the `cir.dyn_cast` operation with more fundamental CIR operations.~ - [x] CIRGen support for the new operation and attributes. - [x] Rewrite the new operation with more fundamental CIR operations in LoweringPrepare. ~This is a draft PR. Now I only added the new operation / attributes, and updated the CIRGen part. The LoweringPrepare for the new operation is not implemented. Hopefully the draft can get some initial feedbacks from the community and make sure it is on the right direction so we don't waste time on wrong things.~ Related issue: llvm#470 .

This PR adds flattening for the `cir.ternary`. This PR is just a copy pasta from the lowering + tests added/fixed. Given the complexity of `switch` flattening, I decided to open one more PR for flattening.

…m codegen approach

This PR adds support for the `long double` type in C/C++. It includes a new CIR type `!cir.long_double` to represent the `long double` type. CIRGen and LLVMIR lowering support for the new type is also added. Since the underlying floating point format used by a `long double` value is implementation-defined, the `!cir.long_double` type is parameterized to include information about the underlying floating point format. Specifically, a `long double` value may have one of the following formats: 1) IEEE-754 binary64 format (i.e. the same format used by `double`); 2) x87 80-bit floating point format; 3) IEEE-754 binary128 format; 4) PowerPC double double format. This PR invents 3 more CIR types to represent the above floating-point formats, and `!cir.long_double` is parameterized by another CIR floating-point type which represents its underlying format: - `!cir.long_double<!cir.double>` represents the 1st variant above; - `!cir.long_double<!cir.f80>` represents the 2nd variant above; - `!cir.long_double<!cir.f128>` represents the 3rd variant above; - `!cir.long_double<!cir.ppc_doubledouble>` represents the 4th variant above. Co-authored-by: Bruno Cardoso Lopes <[email protected]>

…vm#551) ASTAllocaAddressSpace is a target-specific definition specificed by the codegen target info. In this commit, initial support is introduced which asserts that only the default (no qualifier) address space is supported.

Mostly NFC. StructType currently holds optional member variables to track layout specific information. Those are lazily computed at time of layout queries. Change the implementation to use an attribute as the internal implementation - later on we should perhaps incorporate parsing/printing. This is pre req work for computing alignment based on elements offsets, very soon we're gonna also store of array of offsets.

Testcase not added because we are not using the printers and parsers, but upcoming atomic work will exercise the path and testcases.

This PR adds flattening for `SwitchOp`. Despite of the previous PRs, here we have to introduce an operation for the flattening, since later we'll need to create `llvm.switch` in the lowering. So `cir.flat.switch` is a new operation, which barely copied from the dialect. I added several tests as well.

Fix `CastOp::Verify` and invalid.cir error message. Let these error messages with consistent format. llvm#318

…#556) LLVM recently added two families of intrinsics named `llvm.scmp.*` and `llvm.ucmp.*` that generate potentially better code for three-way comparison operations. This PR lowers certain `cir.cmp3way` operations to these intrinsics. Not all `cir.cmp3way` operations can be lowered to these intrinsics. The qualifying conditions are: 1) the comparison is between two integers, and 2) the comparison produces a strong ordering. `cir.cmp3way` operations that are not qualified are not affected by this PR. Qualifying `cir.cmp3way` operations may still need some canonicalization work before lowering. The "canonicalized" form of a qualifying three-way comparison operation yields -1 for lt, 0 for eq, and 1 for gt. This PR converts those non-canonicalized but qualifying `cir.cmp3way` operations to their canonical forms in the LLVM lowering prepare pass. This PR addresses llvm#514 .

NFCI. Any input code still hits an assertion, just a bit down the road.

This patch adds the CIRGen for the following builtin functions: - `alloca`; - `_alloca`; - `__builtin_alloca`; - `__builtin_alloca_uninitialized`. Missing support to add in the future: - Non-default auto initialization setting. The default is to not initialize the allocated buffer, which is simpler to implement. This commit is leaving the skeleton to implement this feature following clang's codegen pattern. - It may be possible that the frontend has set non-default address space for the alloca's return value. This is the case for OpenCL or AMDGPU codes for example. This is handled in clang codegen via address space cast, and is left for future implementation. This commit introduces a guard-rail around this behaviour.

Make logic cleaner and more extensible. Separate collecting `SwitchStmt` information and building op logic into different functions. Add more UT to cover nested switch, which also worked before this pr. This pr is split from llvm#528.

…icOp` (llvm#564) This PR does not introduce any functional changes. It cleans up code in `LowerToLLVM.cpp` and creates all LLVM intrinsic calls through the unified `createCallLLVMIntrinsicOp` function, as suggested by [this comment](llvm#556 (comment)) in llvm#556 . Some LLVM intrinsics already have specialized LLVMIR operations. CIR operations that depend on these intrinsics are lowered to those specialized operations rather than `llvm.call_intrinsic` operation.

…m#565) llvm#563 This PR add cir.cos lowering to MLIR math dialect, now it only surpport single and double float types, I add an assertation for the long double and other unimplemented types --------- Signed-off-by: zhoujing <[email protected]>

ASMParser::parseAttribute is responsible for emitting its own errors or forwarding errors of the parsers below it. There is no reason to emit a subsequent error as it doesn't add extra information to the user. As a driveby, beutify a bit the tests that "relied" on this error and make the expected error easier to read by moving it to the line before.

…m#568) Add left long double types lowering for cos operation llvm#565 --------- Signed-off-by: zhoujing <[email protected]>

This commit introduce CIRGlobalOpLowering and CIRGetGlobalOpLowering for lowering to memref.

This PR relegates the responsibility of printing/parsing CIR_PointerType back to the type itself, getting rid of explicit `cir.ptr` tokens in the assembly format of CIR operations. This means that CIR pointers would now always be printed as `!cir.ptr<type>`, so update all tests that had a space before the bracket (i.e., `!cir.ptr <type>`) or missing the type alias prefix (`cir.ptr` instead of `!cir.ptr`).

This PR is the final fix for issue llvm#499.

…r arithmetic extensions More generalization coming next.

This commit introduce CIRCastOpLowering for lowering to arith.

Do not print in cir.func definition the 'attr { ... }' with coroutine or lambda attributes since they are already printed before the function name. Otherwise redundancy breaks a future parsing. Sort the attributes to be skipped so it is more obvious to see the list of attributes. Improve the tests to check there are no spurious attributes anymore.

…sics specific emission Note that this is a bit different than original LLVM codegen because we are splitting down target specific intrinsics to different files. For now only add AArch64 and x86* as examples, more should come when support for more targets happen.

…ns (llvm#560) This patch adds support for checked arithmetic builtins, including: - `__builtin_add_overflow` and `__builtin_{s|u}add{|l|ll}_overflow`; - `__builtin_sub_overflow` and `__builtin_{s|u}sub{|l|ll}_overflow`; - `__builtin_mul_overflow` and `__builtin_{s|u}mul{|l|ll}_overflow`. This patch adds a new operation `cir.checked_arith` to represent these builtins. Unlike other CIR operations, this new operation has two result values. One for the possibly truncated result, and the other for a boolean flag that indicates whether the operation has overflowed. CIRGen and LLVMIR lowering support for the new operation is both included in this PR.

) As suggested in llvm#401, this PR removes the `get_global_member` test in `CIR/IR/data-member-ptr.cir` as it is redundant. The original comment: llvm#401 (comment)

…p to memref (llvm#585) This commit introduce CIRPtrStrideOpLowering to lower the following pattern to memref load or store. Rewrite %0 = cir.cast(array_to_ptrdecay, %base) %1 = cir.ptr_stride(%0, %index) cir.load %1 To memref.load %base[%index]

This patch update the CIRGen of `dynamic_cast` expressions and make it start to generate `cir.dyn_cast` operations for `dynamic_cast` expressions that cast to a void pointer. This patch also updates the lowering prepare pass so that it lowers such `cir.dyn_cast` operations to the code emitted before this patch.

Testcase introduced in previous commit still commented, with the work in this patch we just move the assertion further.

- Add new operations: `GotoOp` and `LabelOp` and inserts them in the codegen - Adds a pass that replaces `goto` operations with branches to the corresponded blocks (and erases `LabelOp` from CIR) - Update verifiers and tests

@bcardosolopes

Fix llvm#479 . There are three available stages to place the simplification in. * A straightforward method is to extend `fold` method for CastOp. But CIR does not use CanonicalizerPass, so it does not work. * As for somehow equivalent to it, append a pattern to `MergeCleanupsPass`. But now it is mainly for CFG-related simplifications like block merging. I don't know if this is the proper way. Shall we rename it to a broader definition? * Add a new pass for this issue. This is definitely not very reasonable XD. We won't consider it unless we're really out of options. This PR includes the second option. What do you think @bcardosolopes ?

…m#586) This PR add cir.sin lowering to MLIR math dialect. In the future, I will submit a PR to lowering cir.floor, cir.fabs and other operations to MLIR. --------- Co-authored-by: Gao Xiang <gaoxiang@gaoxiang>

…vm#592) This pr adds `cir.ceil` `cir.exp2` `cir.exp` `cir.fabs` `cir.floor` `cir.log` `cir.log10` `cir.log2` `cir.round` `cir.sqrt` lowering to MLIR passes and test files.

…m#594) Same as void pointers `void *`, we treat function pointer arithmetic as `GEP i8`, according to the original behavior of clang ([godbolt](https://godbolt.org/z/EMdvfdTe7)).

…gregates

This PR adds two new CIR floating-point types, namely `!cir.f16` and `!cir.bf16`, to represent the float16 format and bfloat format, respectively. This PR converts the clang extension type `_Float16` to `!cir.f16`, and converts the clang extension type `__bf16` type to `!cir.bf16`. The type conversion for clang extension type `__fp16` is not included in this PR since it requires additional work during CIRGen. Only CIRGen is implemented here, LLVMIR lowering / MLIR lowering should come next.

The empty file `clang/asf` was introduced in e7e05a8. It looks like an accident.

In this PR, we support for dereferencing void pointers as a GNU C extension. This include two modification: - In CIRGen, we support to build ReturnStmt with void return type. - In LowerToLLVM, we support to lower CIR load with void result type to LLVM. It's a part of llvm#579, since I would like to split it to two tasks: - support pointer arithmetic for function types (llvm#594) - **support to dereference void pointer (this PR)**

This patch ensures that only the pretty-print version of function param and result attributes is printed. The tailing dictionary attributes are no longer printed. It also ensures some FuncOp tests are properly validating both parsing and printing.

…ue (llvm#608) Seems the FIXME has been solved since I've confirmed that these CHECK can pass now. Remove the FIXME and recover these CHECK.

There is [a code path](https://github.com/llvm/clangir/blob/3da10fafac66ff125fb59c602e41ad4b4f5cb382/clang/lib/CodeGen/CGExpr.cpp#L2190) missing the counterpart in CIRGen of vector types. When using compound assignments like `a[0] += a[1]`, this code path is activated and end up with NYI.

The constant initialization isn't related to the pointee. We should be able to write #cir.ptr<-1 ： i64> : !cir.ptr<whatever>

…pe (llvm#606) This is the prelude of address space support. Linked issue: llvm#418 . - Add the attribute and implement asm format & type conversion. - Make ops like `cir.global` and `cir.get_global` aware of address space, and solve the latter flag. - Relax the restriction of default alloca address space. Then we can use correct address spaces for languages like OpenCL in future.

…ance without thunk (llvm#569) This PR adds Vtable support for C++ multiple inheritance without thunk. This change contains the CIR codegen and lowering work: 1. `VTableAttr` should allow adding multiple `ArrayAttr` for multi-inheritance. 3. `VTableAddrPointOpLowering` has been fixed for the multi-vtable during the MLIR lowering phase. Example: ```c++ class Mother { virtual void MotherFoo() {} virtual void MotherFoo2() {} } class Father { virtual void FatherFoo() {} } class Child : public Mother, public Father { void MotherFoo() override {} } ``` ```mlir cir.global linkonce_odr @_ZTV5Child = #cir.vtable< {#cir.const_array<[ #cir.ptr<null> : #!cir.ptr<!u8i>, #cir.global_view<@_ZTI5Child> : !cir.ptr<!u8i>, #cir.global_view<@_ZN5Child9MotherFooEv> : !cir.ptr<!u8i>, #cir.global_view<@_ZN6Mother10MotherFoo2Ev> : !cir.ptr<!u8i>]> : !cir.array<!cir.ptr<!u8i> x 4>, #cir.const_array<[ #cir.ptr<-8> : !cir.ptr<!u8i>, #cir.global_view<@_ZTI5Child> : !cir.ptr<!u8i>, #cir.global_view<@_ZN6Father9FatherFooEv> : !cir.ptr<!u8i>] > : !cir.array<!cir.ptr<!u8i> x 3>}> : !ty_anon_struct3 ```

Fix llvm#596

Move it up for visibility, just like the other dialect headers.

Just mimic the table approach from OG codegen, there are thousands of these, it's massive! This doesn't add any new feature yet, continues asserting as before. Coming next: the plan is to reuse the tablegen generated LLVM intrinsics, and pass that down to LLVM lowering.

The alignment is still super conversative but proper support should come next. The added test file also contains a huge pile of builtins we need to support and should allow for incremental support here. Next steps: fix alignement and enable testing for other vld1/vst1 variants.

In this PR I added the support for structural bindings in CIR codegen, to reason `DecompositionDecl` and `BindDecl` properly. Note that since `ArrayInitLoopExpr` is not implemented so binding to arrays is not supported yet.

This commit introduces CIRForOpLowering for lowering to scf. The initial commit only support increment loop with lt or le comparison.

This PR fixes a fail on `llvm_unreachable` for the next case: ``` volatile A vol_a; A foo7() { return vol_a; } ``` Basically, it's just a copy-pasta from the original `code-gen`. Also, I added the `isVolatile` attribute for the `cit.copy` operation

@GET42

This PR fixes the next bug showed in the example below: ``` typedef int (*fn_t)(); int get42() { return 42; } void foo() { fn_t f = get42; } ``` The function type `fn_t` is generated as the variadic one due to no arg types listed, this is the `codegen` feature. And once we store the function pointer to a real function - a pointer to `get42` here has the expected `i32 ()*` type - we get a verification error, so `bitcast` is needed. The original `codegen` doesn't have it because of opaque pointers used, and had the `bitcast` earlier, long time ago: ``` %f = alloca i32 (...)* store i32 (...)* bitcast (i32 ()* @GET42 to i32 (...)*), i32 (...)** %f ```

This commit introduces SCFPreparePass to 1) Canonicalize IV to LHS of loop comparison For example, transfer `cir.cmp(gt, %bound, %IV)` to `cir.cmp(lt, %IV, %bound)`. So we could use RHS as boundary and use `lt` to determine it's an upper bound. 2) Hoist loop invariant operations in condition block out of loop. The condition block may be generated as following which contains the operations produced upper bound. SCF for loop required loop boundary as input operands. So we might need to hoist the boundary operations out of loop. ``` cir.for : cond { %4 = cir.load %2 : !cir.ptr<!s32i>, !s32i %5 = cir.const #cir.int<100> : !s32i <- upper bound %6 = cir.cmp(lt, %4, %5) : !s32i, !s32i %7 = cir.cast(int_to_bool, %6 : !s32i), !cir.boo cir.condition(%7 } body { ```

Don't hook this up with CIRGen just yet. While here update parsing tests to include `atomic(seq_cst)`.

Load coming next.

…lvm#617) The patch resolves [issue llvm#248](llvm#248). It can be considered a subsequent patch to [llvm#373](llvm#373), where the case of empty strings was processed. The new patch adds processing for non-empty strings that may contain trailing zeros, such as: ``` char big_string[100000] = "123"; ``` That is converted to ``` @big_string = #cir.const_array<"123" : !cir.array<!s8i x 3>, trailing_zeros> : !cir.array<!s8i x 100000> ```

One of the builders was adding a retun value to the CallOp when given a void return type. The expected behavior is to not add a return value. Two other minor fixes were added to the return value: its constraint was replaced from variadic to optional and it was assigned a name. This prevents function calls with multiple returns and facilitates access to the single return value, respectively.

lowering var_arg op for ARM64 architecture. This is CIR lowering. This PR modified LoweringPrepare CXXABI code to make LoweringPrepareArm64CXXABI class inherit more generic LoweringPrepareItaniumCXXABI, this way lowering var_arg would be only meaningful for arm64 targets and for other arch its no op for now. The ABI doc and detailed algorithm description can be found in this official doc. [](https://github.com/ARM-software/abi-aa/blob/617079d8a0d45bec83d351974849483cf0cc66d5/aapcs64/aapcs64.rst#appendix-variable-argument-lists)

…lvm#630) This pr adds cir.shift lowering to MLIR passes and test files.

With C source code, we would able to update the CIR tests when needed.

One more step into fixing overall alignment requirements.

This patch adds a new CallConvLowering pass that aims to lower the calling conventions of the functions in the module. It also includes a new Clang command line option to enable it. Also, it is considered a part of the lowering prepare set of passes, as it is unlikely to be used elsewhere in the pipeline. Since this will be dealing with ABI/Target-specific information, it requires AST info. For this reason, it can only be executed through the clang driver or cc1 tool for now as CIR does not encode AST info. This pass is disabled by default and can be enabled by passing the flag `-fclangir-call-conv-lowering`. Once this pass is more mature, it should be enabled by default as a required step to lower to LLVM Dialect.

This PR adds the following operations for the builtin binary fp2fp functions: - `cir.copysign` for `__builtin_copysign`; - `cir.fmax` for `__builtin_fmax`; - `cir.fmin` for `__builtin_fmin`; - `cir.fmod` for `__builtin_fmod`; - `cir.pow` for `__builtin_pow`. This PR also includes CIRGen support for these new operations.

…uncOp (llvm#641) CIRGlobalValueInterface inherits from mlir::Symbol as it should, and GlobalOp and FuncOp now has interface mlir::Symbol through CIRGlobalValueInterface and this PR basically make function isDeclarationForLinker into the CIRGlobalValueInterface interface. We also change some call sites of isDeclaration to use CIRGlobalValueInterface when its appropriate.

…#645) This pr adds cir.bit.clz and cir.bit.ctz lowering to MLIR passes and test files. I will complete the lowering of other `cir.bit` operations in subsequent PRs.

Now that alignment computation is correct for neon, add more neon types for load/store.

mlir::cir::ZeroInitConstOp was replaced with llvm.mlir.zero resolves [llvm#627](llvm#627)

Close llvm#633. This patch introduces `-fclangir-analysis-only` option to allow the users to consume the AST to the CIR (and potential analysis passes, this can be done by specifying `-Xclang -fclangir-lifetime-check=""` now or some default value in following patches) and also generating the LLVM IR by the traditional code gen path. This will be helpful to use CIR with real world projects without worrying the correctness and completeness of CIR CodeGen part.

This pr adds cir.bit.ffs cir.bit.parity cir.bit.clrsb cir.bit.popcount lowering to MLIR passes and test files.

This PR adds support for atomic `__sync_fetch_and_add`. Basically it's a copy-pasta from the original `codegen`. The only thing that I doubt about is what exact operation I need to create in CIR. The first approach I used was to create `AtomicRMW` operation in CIR. But as far as I see I can use the existing `AtomicFetch` instead. Is it correct? or it's better to add a new op here?

Moves all feature guarding static methods into a to a single header file, centralizing the tracking of missing features in a common place regardless of where it impacts the compilation pipeline. It also moves the feature guarding logic into CIR's root include folder so that any CIR library may use it.

Make lowering result of case range smart. Resolve llvm#632

) This patch adds LLVM lowering support for unary fp2fp builtins. Those builtins that should be lowered to runtime function calls are lowered to such calls during lowering prepare. Other builtins are lowered to LLVM intrinsic calls during LLVM lowering.

This patch adds a new TargetLowering library that intends to add supoort for lowering CIR code to target specific CIR code. It is largely based on the original codegen library used to lower AST nodes to ABI/Target -specific LLVM IR instructions. Because of this, each file has a comment specifying the original codegen file that inspired the new file. The idea is that anyone who wishes to expand this library can look at the original codegen file to understand how to implement the new feature. In some cases, CIRGen defers the handling of ABI/target-specific details for a later stage in the pipeline. One reason for this is to keep the intermediate representation on a higher-level, which makes it easier to reason about and to perform optimizations. However, we still need to lower such representation to a target-specific format at some point. Some examples are ctor/dtors and calling conventions, which are not fully handled by CIRGen. The new library will be responsible for these lowerings. Some files are empty but will eventually be used and a few getters and methods where added to avoid unused warnings. Missing features in this library are tracked in a dedicated MissingFeature.h header.

Resolve llvm#532 . Support CIRGen of `ExtVectorElementExpr` that includes swizzle `v.xyx` and subscription `v.s0`.

This reverts commit f4d538f. It's causing a circular dependency in shared lib builds. See llvm#655

Without this patch, CIR CodeGen continue to generate in the same block after `cir.break` and `cir.continue`, which would cause verification error because `cir.break` and `cir.continue` should appear at the end of blocks. This patch creates a new dangling block after generating `cir.break` and `cir.continue` to fix the issue. This will fix llvm#323.

* New `CastKind::addrspace_cast` for `cir.cast` * `TargetCIRGenInfo::performAddrSpaceCast` helper for non-constant values only * CIRGen for address space casting of pointers and references * Lowering to LLVM

) This PR adds support for ` __sync_bool_compare_and_swap` and ` __sync_val_compare_and_swap`.

…f.condition, scf.while (llvm#636) This pr intruduces CIRConditionLowering and CIRWhileLowering for lowering to scf.

This pr introduces CIRIfOpLowering for lowering cir.if to scf.if

…ations

Assumptions about values having a defining op can be misleading when block arguments are involved.

When loweringPrepare cg.var_arg for AArch64, we create multiple basic blocks, but didn't really get ordering of the blocks in the blocklist of the parent region right. That is, we didn't make sure the last of the block list is the naturally last block (exit) of the region. This PR fixes this problem. If we don't fix this problem, FlattenCFGPass will fail verification because CIRScopeOpFlattening in this pass is onlyy expecting to see cir.yield op in the last block of the region's block list.

…d store (llvm#674) Continue the work of llvm#613 . Original CodeGen treat vec3 as vec4 to get aligned memory access. This PR enable these paths.

This patch implements the lowering of function calls that receive and return void. In practice, nothing has to be done (at least for the x86 ABI), so this case is used as a primer for the target lowering library since it helps populate the base logic for handling calling convention lowering of function calls.

This patch implements the lowering of function definitions with no arguments and returns. In pratice, nothing has to be done (at least for the x86 ABI), so this case is used as a primer for the target lowering library since it helps populate the base logic for handling calling convention lowering of function definitions.

Continue the work of llvm#652 . Test the branch of null pointer expressions with side effects.

…method (llvm#663) This pr is a part of llvm#593 . Move RemoveRedundantBranches logic into BrOp::fold method and modify tests.

@test

…lvm#684) This PR is to fix the issue llvm#658 . Now we can get the correct result using the following command. ``` echo "void test(int *){}" | ./build/Debug/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -fclangir -fno-clangir-direct-lowering -emit-mlir -o - ``` result: ``` module attributes {cir.lang = #cir.lang<c>, cir.sob = #cir.signed_overflow_behavior<undefined>, cir.triple = "x86_64-unknown-linux-gnu", dlti.dl_spec = #dlti.dl_spec<#dlti.dl_entry<!llvm.ptr, dense<64> : vector<4xi64>>, #dlti.dl_entry<i1, dense<8> : vector<2xi64>>, #dlti.dl_entry<f16, dense<16> : vector<2xi64>>, #dlti.dl_entry<i32, dense<32> : vector<2xi64>>, #dlti.dl_entry<i8, dense<8> : vector<2xi64>>, #dlti.dl_entry<i16, dense<16> : vector<2xi64>>, #dlti.dl_entry<!llvm.ptr<272>, dense<64> : vector<4xi64>>, #dlti.dl_entry<!llvm.ptr<271>, dense<32> : vector<4xi64>>, #dlti.dl_entry<!llvm.ptr<270>, dense<32> : vector<4xi64>>, #dlti.dl_entry<f128, dense<128> : vector<2xi64>>, #dlti.dl_entry<f64, dense<64> : vector<2xi64>>, #dlti.dl_entry<f80, dense<128> : vector<2xi64>>, #dlti.dl_entry<i128, dense<128> : vector<2xi64>>, #dlti.dl_entry<i64, dense<64> : vector<2xi64>>, #dlti.dl_entry<"dlti.stack_alignment", 128 : i64>, #dlti.dl_entry<"dlti.endianness", "little">>, llvm.data_layout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:32:64-S128"} { func.func @test(%arg0: memref<i32> loc(fused[#loc3, #loc4])) { %alloca = memref.alloca() {alignment = 8 : i64} : memref<memref<i32>> loc(#loc7) memref.store %arg0, %alloca[] : memref<memref<i32>> loc(#loc5) return loc(#loc2) } loc(#loc6) } loc(#loc) ``` And the test/CIR/Lowering/ThroughMLIR/dot.cir now passes the test, so I have removed the XFAIL flag.

Some function attributes are also callsite attributes, for instance, nothrow. This means they are going to show up in both. We don't support that just yet, hence the PR. CIR has an attribute `ExtraFuncAttr` that we current use as part of `FuncOp`, see CIROps.td. This attribute also needs to be added to `CallOp` and `TryCalOp`. Right now, In `CIRGenCall.cpp: AddAttributesFromFunctionProtoType` fills in `FuncAttrs`, but doesn't use it for anything. We should use the `FuncAttrs` result to populate constructing a `ExtraFuncAttr` and add it to the aforementioned call operations.

…R vector Dialect (llvm#681) This pr adds cir.vec.create, extract, insert op lowering to MLIR passes and test files. Can we lower the vector-related operations in CIR to the vector dialect? This is feasible, although the vector dialect hasn't been used in the CIRToMLIR conversion before. If this lowering is acceptable, I will complete the remaining operations' lowering in the next PR. If there is a more suitable dialect, feel free to discuss it.

) This PR adds LLVM lowering support for data member pointers. It includes the following changes: - ~~The `#cir.data_member` attribute now has a new parameter named `memberOffset`. When the data member pointer is not null, this parameter gives the offset of the pointed-to member within its containing object. This offset is calculated by target ABI.~~ - ~~A new attribute `#cir.data_member_ptr_layout` is added. It contains ABI-specific layout information about a data member pointer that is required to lower it to LLVM IR. This attribute is attached to the module op, and it is queried during LLVMIR lowering to obtain the lowering information in it.~~ - Some CIRGen of the data member pointers is refactored to follow the upstream CodeGen skeleton.

This reverts commit 901f532. Revert as a prereq to revert llvm#668 This broke the build: ``` /usr/bin/ld: lib/libMLIRCIRTransforms.a(LoweringPrepare.cpp.o): in function `(anonymous namespace)::LoweringPreparePass::lowerVAArgOp(mlir::cir::VAArgOp)': /local/home/dolsen/clangir/clang/lib/CIR/Dialect/Transforms/LoweringPrepare.cpp:340: undefined reference to `cir::CIRDataLayout::CIRDataLayout(mlir::ModuleOp)' /usr/bin/ld: lib/libTargetLowering.a(LowerTypes.cpp.o): in function `cir::CIRDataLayout::CIRDataLayout(llvm::StringRef, mlir::ModuleOp)': /local/home/dolsen/clangir/clang/include/clang/CIR/Dialect/IR/CIRDataLayout.h:31: undefined reference to `cir::CIRDataLayout::reset(llvm::StringRef)'`' ``` Steps to reproduce: ``` $ cmake -GNinja -DCMAKE_INSTALL_PREFIX=/<some-path>/clangir-install "-DLLVM_ENABLE_PROJECTS=clang;mlir" -DCLANG_ENABLE_CIR=ON -DLLVM_TARGETS_TO_BUILD=host -DCMAKE_BUILD_TYPE=Debug ../clangir/llvm $ ninja install ```

This reverts commit 66bb15b. This broke the build: ``` /usr/bin/ld: lib/libMLIRCIRTransforms.a(LoweringPrepare.cpp.o): in function `(anonymous namespace)::LoweringPreparePass::lowerVAArgOp(mlir::cir::VAArgOp)': /local/home/dolsen/clangir/clang/lib/CIR/Dialect/Transforms/LoweringPrepare.cpp:340: undefined reference to `cir::CIRDataLayout::CIRDataLayout(mlir::ModuleOp)' /usr/bin/ld: lib/libTargetLowering.a(LowerTypes.cpp.o): in function `cir::CIRDataLayout::CIRDataLayout(llvm::StringRef, mlir::ModuleOp)': /local/home/dolsen/clangir/clang/include/clang/CIR/Dialect/IR/CIRDataLayout.h:31: undefined reference to `cir::CIRDataLayout::reset(llvm::StringRef)'`' ``` Steps to reproduce: ``` $ cmake -GNinja -DCMAKE_INSTALL_PREFIX=/<some-path>/clangir-install "-DLLVM_ENABLE_PROJECTS=clang;mlir" -DCLANG_ENABLE_CIR=ON -DLLVM_TARGETS_TO_BUILD=host -DCMAKE_BUILD_TYPE=Debug ../clangir/llvm $ ninja install ```

fix build failure undefined reference to `cir::CIRDataLayout::CIRDataLayout(mlir::ModuleOp)' by breaking circular dependency caused by the fact CIRDataLayout was in CIR Codegen

Essentially re-applies llvm#668 and llvm#678, but also includes llvm#687 which patched build introduced by the other two PRs. Closes llvm#691

This PR adds new ops, CIRGen, and LLVM lowering support for the following unary fp2int builtins and libc functions: - `__builtin_lround` family of builtins and `lround` family of libc functions; - `__builtin_llround` family of builtins and `llround` family of libc functions; - `__builtin_lrint` family of builtins and `lrint` family of libc functions; - `__builtin_llrint` family of builtins and `llrint` family of libc functions.

* SPIRV64 TargetInfo * Calling convention `SPIR_KERNEL` * Minimal ABI with Direct/Extend for arguments and Ignore for return --------- Co-authored-by: Vinicius Couto Espindola <[email protected]>

…ZdlPV clang's choice of delete here changes from just hte pointer version to the sized version. Change the test to do the same

….vec.cmp to MLIR (llvm#694) This PR does Three things: 1. Fixes the BinOp lowering to MLIR issue where signed numbers were not handled correctly, and adds support for vector types. The corresponding test files have been modified. 2. Fixes the CmpOp lowering to MLIR issue where signed numbers were not handled correctly And modified test files. 3. Adds cir.vec.cmp lowering to MLIR along with the corresponding test files. I originally planned to complete the remaining cir.vec.* lowerings in this PR, but it seems there's quite a lot to do, so I'll split it into multiple PRs. --------- Co-authored-by: Kritoooo <[email protected]>

…perator (llvm#677) This PR is to fix the missing **nsw** flag in issue llvm#664 regarding add, mul arithmetic operations. there is also a problem with unary operations such as **Inc ,Dec,Plus,Minus and Not** . which should also have 'nsw' flag [example](https://godbolt.org/z/q3o3jsbe1). This part should need to be fixed through lowering.

This patch is a preparation for the AArch64 calling convention lowering. It adds the basic infrastructure to initialize the AArch64 ABI details and validates it against a trivial void return and argument call conv lowering.

as title. In this PR 1. make setDSOLocal an interface function. 2. implemented shouldAssumeDSOLocal function in CIRGenModule, using the same skeleton as shouldAssumeDSOLocal in OG's CodeGenModule.cpp. 3. added call sites of setDSOLocal within CIRGenModule, like what's in OG's CodeGenModule. 4. fixed printing format 5. LLVM lowering 6. keep CIRGenModule::setDSOLocal(mlir::Operation *Op) wrapper at call sites, so if we make changes to interface, we don't have to touch call sites since there are many. We don't have LLVM test for this PR yet, and it will be addressed by the next PR,: **TODO in the next PR:** 1. Implement setNonAliasAttributes in CIRGenModule.cpp, which should be called by CIRGenModule::buildGlobalFunctionDefinition. That way, we will set dso_local correctly for all func ops who have defs in the module. That way we should have LLVM test case in this next PR. detailed explanation below: Since LLVM asm printer omits dso_local in [isImplicitDSOLocal](https://github.com/llvm/clangir/blob/main/llvm/lib/IR/AsmWriter.cpp#L3689)(), and all we cover so far in CIR all fall into this category, we're not able to have a LLVM test. However, the case [isDeclarationForLinker()](https://github.com/llvm/clangir/blob/c28908396a3ba7bda6345907233e4f5c4e53a33e/clang/lib/CodeGen/CodeGenModule.cpp#L1655) should have a lot of test examples as all func defs should have dso_local, We don't have it CIR is because A to-do in our CG. When OG is building func def, after code is generated, it will call setDSOLocal again via setNonAliasAttributes—>SetCommonAttributes—>setGVProperties. The key difference is now GV is not declaration anymore. so satisfies the test if (!GV->isDeclarationForLinker()) return true; https://github.com/llvm/clangir/blob/f78f9a55e7cd6b9e350556e35097616676cf1f3e/clang/lib/CodeGen/CodeGenModule.cpp#L5864 But our CG missed this step of calling setNonAliasAttributes so it won’t give setDSOLocal another chance to get it right https://github.com/llvm/clangir/blob/c28908396a3ba7bda6345907233e4f5c4e53a33e/clang/lib/CIR/CodeGen/CIRGenModule.cpp#L496 **TODO in the next next PR** 2. add call to setDSOLocal in other parts of CG other than CIRGenModule. 3. implement DefaultVisibility check, didn't do in this PR as LLVM::DefaultVisibility has no direct counterpart in [MLIR::](mlir::SymbolTable::Visibility). Therefore, it takes care examination of cases to see what is the best emulation of hasDefaultVisibility in MLIR/CIR context as far as dsolocal is concerned. **TODO in future** other than DefaultVisibility check, we didn't implement canBenefitFromLocalAlias as it depends on other missing features like setComDat. There is a lot of cases we need to cover, so this is just the first step!

…vm#703) Mechanical rewrite to use the corresponding free functions; fixes llvm#702. I used a slightly modified version of the `clang-tidy` check provided in https://discourse.llvm.org/t/psa-deprecating-cast-isa-methods-in-some-classes/70909 to rewrite the C++ source files, regular expressions for the TableGen files, and manual cleanups where needed (e.g. chains like `x.foo().cast<A>().bar().cast<B>()`) I applied the following heuristic to determine which namespace prefix to use: - If the target type is not qualified, and the TU has `using namespace mlir` or the code is inside the `mlir` namespace -> use a plain `isa`/`cast`/... - Exception: Always qualify inside custom types and attributes, because their base classes define the very members we want to get rid of. - Else. i.e. the target type is qualified as `::mlir::` or `mlir::`, use that prefix. The `clang-tidy` check also rewrote `dyn_cast_or_null` to `dyn_cast_if_present`. I think that's useful because the former variant is going to be deprecated as well in the future. I'm using `-Werror=deprecated-declarations` to test the change (see 6b7420a); this required also changing two occurrences of `StringRef::equals` to `==`. I could also just drop the commit here; maybe we want to enable `-Werror` in general (there aren't too many other warnings left in the codebase). --------- Signed-off-by: Julian Oppermann <[email protected]>

) This PR implements the solution B as discussed in llvm#682. * Use the syntax `cir.ptr<T>` `cir.ptr<T, addrspace(target<0>)` `cir.ptr<T, addrspace(opencl_private)>` * Add a new `AddressSpaceAttr`, which is used as the new type of addrspace parameter in `PointerType` * `AddressSpaceAttr` itself takes one single `int64_t $value` as the parameter * TableGen templates to generate the conversion between `clang::LangAS -> int64_t $value <-> text-form CIR`

Adds the necessary bits to lower arguments and return values of type unsigned int for the x86_64 target. This includes adding logic for extend and direct argument-passing kinds.

Implement vector constants in ClangIR. Resolves issue llvm#498 - Add a `cir.const_vec`, simlar to `cir.const_array` and `cir.const_struct` Create a new kind of attribute, `cir::ConstVectorAttr` in the code or `#cir.const_vector` in the assembly, which represents a compile-time value of a `cir::VectorType`. The values for the elements within the vector are stored as attributes within an `mlir::ArrayAttr`. When doing CodeGen for a prvalue of vector type, try to represent it as `cir.const #cir.const_vector` first. If that fails, most likely because some of the elements are not compile-time values, fall back to the existing code that uses a `cir.vec.create` operation. When lowering directly to LLVM IR, lower `cir.const #cir.const_vector` as `llvm.mlir.constant(dense<[...]> : _type_) : _type_`. When lowering through other MLIR dialects, lower `cir.const #cir.const_vector` as `arith.constant dense<[...]> : _type_`. No new tests were added, but the expected results of the existing tests that use vector constants were updated.

This PR fixes a bug during the CIRGen of fp16 unary operations. Before this patch, for the expression `-x` where `x` is a fp16 value, CIRGen emits the code like the following: ```mlir %0 = cir.cast float_to_float %x : !cir.f16 -> !cir.float %1 = cir.cast float_to_float %0 : !cir.float -> !cir.f16 %2 = cir.unary minus %1 : !cir.fp16 ``` The expected CIRGen should instead be: ```mlir %0 = cir.cast float_to_float %x : !cir.f16 -> !cir.float %1 = cir.unary minus %0 : !cir.float %2 = cir.cast float_to_float %1 : !cir.float -> !cir.f16 ``` This PR fixes this issue.

Adds the necessary bits to lower arguments and return values of type unsigned int for the x86_64 target.

…#707) In this PR: as title we added setNonAliasAttributes in the skeleton of OG's setNonAliasAttributes, and call this function in buildGlobalFunctionDefinition after code for FuncOP is generated. This is needed for CIR OG to know FuncOP is not declaration anymore, thus giving shouldAssumeDsoLocal another run to make dso_local right. A couple of notes about test; 1. having to changed driver.c, because in terms of dso_local for func, masOS is different from other targets as even in OG, as [macOS is !isOSBinFormatELF()](https://github.com/llvm/clangir/blob/f78f9a55e7cd6b9e350556e35097616676cf1f3e/clang/lib/CodeGen/CodeGenModule.cpp#L1599), thus even OG doesn't set dso_local for its functions. 3. most of functions in existing tests still not getting dso_local in LLVM yet because they fall into case of [(RM != llvm::Reloc::Static && !LOpts.PIE) ](https://github.com/llvm/clangir/blob/f78f9a55e7cd6b9e350556e35097616676cf1f3e/clang/lib/CodeGen/CodeGenModule.cpp#L1605C6-L1605C47), which is more complicated to implement as we need to get canBenefitFromLocalAlias right. So I treated it as a missing feature and default it to false. We gonna leave it to another PR to address. In this PR, I just added additional test with -fpie option to my test so we get dso_local for functions without having to deal with this case. Next 2 PRs: PR1. call setNonAliasAttributes in buildGlobalVarDefinition, after initialization for GlobalOP is found, similar to FuncOp. didn't to it in this PR as there are many more test cases needed to be fixed/added for this case. PR2: try to implement canBenefitFromLocalAlias.

OG's counterpart is [here](https://github.com/llvm/clangir/blob/b41d427cc72057adadbdbd2f5e54fdb46592a52a/clang/lib/CodeGen/CGExpr.cpp#L5607)

This PR implements the last piece to make CIR catch up upstream CodeGen on `dynamic_cast` support. It ports an upstream optimization "exact cast" to CIR. The basic idea of exact cast is when `dynamic_cast` to a final class, we don't have to call into the runtime -- we could just check if the dynamic type of the source object is exactly the destination type by quickly comparing the vtable pointers. To give a concrete example of this optimization: ```cpp struct Base { virtual ~Base(); }; struct Derived final : Base {}; Derived *test(Base *src) { return dynamic_cast<Derived *>(src); } ``` Without the optimization, we have to call the runtime function `__dynamic_cast` to do the heavy and slow type check. After enabling the optimization, we could quickly carry out the runtime type check by inline checking whether the vtable ptr of `src` points to the vtable of `Derived`. This PR also fixes a bug in existing dynamic_cast CIRGen code. The bug mistakenly removes the insertion point after emitting a call to bad_cast, causing the CIRGen of any follow up statements to crash.

This PR adds LLVM lowering support for `_Float16` type. The only change we need to make here is adding a new type converter to the LLVM lowering pass. The majority of this PR is tests that check the generated LLVM IR. Later I'll add another separate PR that adds LLVM lowering support for the `__bf16` type. This PR is already big enough.

…#713)

This PR adds LLVM lowering support for the `__bf16` type. To support its LLVM lowering, we just need to add a new type conversion rule to the LLVM lowering pass. The majority of this PR are the new LLVM IR checks in the tests.

Implements approach 2 in llvm#703 (comment), as discussed in the community call. Signed-off-by: Julian Oppermann <[email protected]>

This PR adds `!cir.complex` type to model the `_Complex` type in C. It also contains support for its CIRGen. In detail, this patch adds the following CIR types, ops, and attributes: - The `!cir.complex` type is added to model the `_Complex` type in C. This type is parameterized with the type of the components of the complex number, which must be either an integer type or a floating-point type. - ~The `#cir.complex` attribute is added to represent a literal value of `_Complex` type. It is a struct-like attribute that provides the real and imaginary part of the literal `_Complex` value.~ - ~The `#cir.imag` attribute is added to represent a purely imaginary number.~ - The `cir.complex.create` op is added to create a complex value from its real and imaginary parts. - ~The `cir.complex.real` and `cir.complex.imag` op is added to extract the real and imaginary part of a value of `!cir.complex` type, respectively.~ - The `cir.complex.real_ptr` and `cir.complex.imag_ptr` op is added to derive a pointer to the real and imaginary part of a value of `!cir.complex` type, respectively. CIRGen support for some of the fundamental complex number operations is also included. ~Note the implementation diverges from the original clang CodeGen, where expressions of complex types are handled differently from scalars and aggregates. Instead, this patch treats expressions of complex types as scalars, as such expressions can be simply lowered to a CIR value of `!cir.complex` type.~ This PR addresses llvm#445 .

There's no good reason to add our own switch here, given there's existing machinery to compute these names. Fallback to that instead.

LLVM support coming next.

… value (llvm#719) This commit fixes GlobalOp lowering for floating without initial value. It implies to be initialized with zeros. E.g. float f[100]; double d;

…p::fold method (llvm#663)" This reverts commit 3b9f698.

ClangIR was failing on ``` __atomic_compare_exchange_n(&a, &old, 42, true, 5, 5); ``` The `true` was the problem. It would work with a literal `0` or `1`, but not with a literal `true` or `false`. The bug was in `isCstWeak` in CIRGenAtomic.cpp, which was only looking for an integral constant. It didn't recognize a boolean constant and was falling back on the non-constant path, which isn't implemented yet. Rewrite `isCstWeak` to check for both intergral and boolean constants.

This PR adds LLVM lowering for the following operations related to complex numbers: - `cir.complex.create`, - `cir.complex.real_ptr`, and - `cir.complex.imag_ptr`. The LLVM IR generated for `cir.complex.create` is a bit ugly since it includes the `insertvalue` instruction, which typically is not generated in upstream CodeGen. Later we may need further CIR canonicalization passes to try folding `cir.complex.create`.

This PR fixes the bug described as in llvm#727 (comment). It should resolve the crash reported in llvm#727 .

This PR introduces a new attribute `OpenCLKernelMetadataAttr` to model the OpenCL kernel metadata structurally in CIR, with its corresponding implementations of CodeGen, Lowering and Translation. The `"TypeAttr":$vec_type_hint` part is tricky because of the absence of the signless feature of LLVM IR, while SPIR-V requires it. According to the spec, the final LLVM IR should encode signedness with an extra `i32` boolean value. In this PR, the droping logic from CIR's `TypeConverter` is still used to avoid code duplication when lowering to LLVM dialect. However, the signedness is then restored (still capsuled by a CIR attribute) and dropped again in the translation into LLVM IR.

… BinOp (llvm#720) This commit extends the pass to support loop invariant BinOp hoisting as SCF forOp boundary. E.g. // (100 - 1) should be hoisted out of loop. // So the boundary could be input operand to generate SCF forOp. for (int i = 0; i < 100 - 1; ++i) {}

…#729) Previously, when lowering induction variable in forOp, we removed the IV load and replaced the users with SCF.IV. The CIR IV users might still CIR operations during lowering forOp. It caused the issue that CIR operation contained SCF.IV as operand which is MLIR integer type instead CIR type. This comment lower CIR load IV_ADDR with ARITH addi SCF.IV, 0 So SCF.IV can be propagated by OpAdaptor when lowering individual IV users. This simplifies the lowering and fixes the issue. The redundant arith.addi can be removed by later MLIR passes.

LLVM lowering for the following operations is introduced in llvm#616 and llvm#651: `cos`, `exp`, `exp2`, `log`, `log10`, `log2`, `sin`, `sqrt`, `fmod`, and `pow`. However, they are not lowered to their corresponding LLVM intrinsics; instead they are transformed to libc calls during lowering prepare. This does not match the upstream behavior. This PR tries to correct this mistake. It makes all CIR FP intrinsic ops lower to their corresponding LLVM intrinsics (`fmod` is a special case and it is lowered to the `frem` LLVM instruction).

For now only handle the cir.try part, cir.catch is coming next. Using flat cir for tests make this easy to incrementally build.

as title. document will be in another PR as it seems to be a different upstream branch

…lvm#733) In [this commit](llvm@e5d840b), minimal support for Darwin aarch64 triples was added. But TargetLoweringInfo was not updated correspondingly. This could lead to a failure of the test `driver.c` with CallConvLowering pass enabled (or `LowerModule` used in some other ways). This PR fixes the inconsistency and adds an extra missing feature flag for it.

Although currently LowerModule is not ready for formal usage, we need it for target-specific lowering to LLVM. This PR temporarily public the symbol `createLowerModule` to reuse the logic of preparing a `LowerModule`, making it easier for future refactor (making `TargetLoweringInfo` available for most stages in CIR Lowering).

In this PR, we 1. implement defaultVisibility as far as dsolocal is concerned, currently is either MLIR::Visibility isPublic() or isPrivate(). Now, we don't handle hiddenVisibility and protectedVisibility from AST. I put missFeature assert so that If in anyway we translate hiddenVisibility or protectedVisibility into mlir::SymbolTable::Visibility::Private (hopefully not for it'd be confusing), then we need to revise this defaultVisibility setting. 2. call setNonAliasAttributes on global op upon discovery of its initialization, thus we have globals dso_local correctly set. Still missing is lots of function should have dso_local set, but the all depend on comDat implementation, which will come from next PR within the next few days.

OG codegen does not generate any exception related content when there are not calls happening inside the try block. For now we mimic OG and do the same, until we see a concrete use case that would have used emitting this code.

Commits on Jul 15, 2024

Realize RG and GET_RG op

566hub committed Jul 15, 2024

Configuration menu

View commit details

Copy full SHA for b7fd5bb

Browse repository at this point

Copy the full SHA

b7fd5bb View commit details

Browse the repository at this point in the history

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[CIR][CIRGen] Add support for global named registers #741

[CIR][CIRGen] Add support for global named registers #741

Commits on Jun 20, 2024

Commits on Jun 21, 2024

Commits on Jun 22, 2024

Commits on Jun 25, 2024

Commits on Jun 26, 2024

Commits on Jun 27, 2024

Commits on Jun 30, 2024

Commits on Jul 1, 2024

Commits on Jul 2, 2024

Commits on Jul 3, 2024

Commits on Jul 4, 2024

Commits on Jul 8, 2024

Commits on Jul 9, 2024

Commits on Jul 10, 2024

Commits on Jul 11, 2024

Commits on Jul 12, 2024

Commits on Jul 13, 2024

Commits on Jul 15, 2024

[CIR][CIRGen] Add support for global named registers #741

Are you sure you want to change the base?

[CIR][CIRGen] Add support for global named registers #741

Commits on Jun 20, 2024

Commits on Jun 21, 2024

Commits on Jun 22, 2024

Commits on Jun 25, 2024

Commits on Jun 26, 2024

Commits on Jun 27, 2024

Commits on Jun 30, 2024

Commits on Jul 1, 2024

Commits on Jul 2, 2024

Commits on Jul 3, 2024

Commits on Jul 4, 2024

Commits on Jul 8, 2024

Commits on Jul 9, 2024

Commits on Jul 10, 2024

Commits on Jul 11, 2024

Commits on Jul 12, 2024

Commits on Jul 13, 2024

Commits on Jul 15, 2024