[CIR] Fix C++ array delete lowering to match classic codegen #1968
+170,910
−44,670
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Implement base-2 exponential intrinsic as part of llvm#1192
…lvm#1671) Hi, This is my first here! Tried to mirror some of the patterns already presented in both the codegen lib and its tests I'm very excited to start contributing and potentially making an impact in this project! feedback is much appreciated.
convert from codegen
```c++
assert(!Base.isVirtual() && "should not see vbases here");
auto *BaseRD = Base.getType()->getAsCXXRecordDecl();
Address V = CGF.GetAddressOfDirectBaseInCompleteClass(
Dest.getAddress(), CXXRD, BaseRD,
/*isBaseVirtual*/ false);
AggValueSlot AggSlot = AggValueSlot::forAddr(
V, Qualifiers(),
AggValueSlot::IsDestructed,
AggValueSlot::DoesNotNeedGCBarriers,
AggValueSlot::IsNotAliased,
CGF.getOverlapForBaseInit(CXXRD, BaseRD, Base.isVirtual()));
CGF.EmitAggExpr(InitExprs[curInitIndex++], AggSlot);
if (QualType::DestructionKind dtorKind =
Base.getType().isDestructedType())
CGF.pushDestroyAndDeferDeactivation(dtorKind, V, Base.getType());
```
Moved rd related intrinsic tests, to a different file similar to `clang/test/CodeGen/X86/rd-builtins.c`. Let me know if that's the right call. related: llvm#1404
Update `__real__` operation to use ComplexRealOp and act directly on the complex value. Ref: llvm/llvm-project#144235 (review)
Update `__imag__` operation to use ComplexRealOp and act directly on the complex value. Ref: llvm/llvm-project#144235 (review)
… tzcnt_u64 (llvm#1691) Related: llvm#1404 Implements codegen for the X86 builtins `tzcnt_u16`, `tzcnt_u32`, and `tzcnt_u64`. While adding tests for both the Intel and AMD variants of BMI intrinsics, I ran into issues when placing them in the same file. Both `_tzcnt_u16` (Intel) and `__tzcnt_u16`(AMD) map to the same inline wrapper in <immintrin.h>. Whether they're isolated or both are present in a test file, Clang emits only one definition (`__tzcnt_u16`) which I think causes FileCheck mismatches i.e., the CHECK lines for the Intel version (`test_tzcnt_u16`) would fail when looking for `_tzcnt_u16`. I tried updating the CHECK lines for the Intel test to match the emitted symbol (`__tzcnt_u16`), but it still failed unless the Intel test was run in isolation, and only when CHECK was updated to `_tzcnt_u16` even though `__tzcnt_u16` is what is emitted. I also experimented with split-file to isolate the tests, but that didn’t resolve the issue either. To keep the tests independent, I split the Intel and AMD tests into separate files. Was wondering if this was fine as in OG clang, both Intel and AMD variants are in the same file (https://github.com/llvm/clangir/blob/main/clang/test/CodeGen/X86/bmi-builtins.c)
As we need to preserve the ContinueOp for inner loops when we convert for outer while-loops, we must not mark cir dialect as illegal. Otherwise, MLIR rejects this kind of preservation and considers it as a pass failure. It seems we need another way to check whether the CIR is fully lowered. Co-authored-by: Yue Huang <yue.huang@terapines.com>
Backport ChooseExpr for Scalar expr
Backporting the VecCreateOp Folder from the upstream
Backporting the VecSplatOp simplifier from the upstream
Implement ChooseExpr for ComplexType
Backporting the VecTernaryOp folder
In [libstdc++ std::variant implementation](https://github.com/gcc-mirror/gcc/blob/b0419798447ae25de2f58d1a695db6dadb5d8547/libstdc%2B%2B-v3/include/std/variant#L387-L394), union without any fields is used. According to current CodeGen logic, append 1 byte padding for this kind of union. Handle this union in `mlir::RecordType` for getLargestMember` return nullptr also. The original LLVM IR ```llvm %union.EmptyUnion = type { i8 } @__const._Z2f0v.e = private unnamed_addr constant %union.EmptyUnion undef, align 1 define dso_local void @_Z2f0v() #0 { entry: %e = alloca %union.EmptyUnion, align 1 call void @llvm.memcpy.p0.p0.i64(ptr align 1 %e, ptr align 1 @__const._Z2f0v.e, i64 1, i1 false) ret void } ``` The CIR lowered LLVM IR ```llvm %union.EmptyUnion = type { i8 } define dso_local void @_Z2f0v() #0 { %1 = alloca %union.EmptyUnion, i64 1, align 1 store %union.EmptyUnion undef, ptr %1, align 1 ret void } ``` The major different is original use global const and memcpy, the current use store. The difference between the two is not related to this revision.
Two things: 1. Added some NYI placeholders 2. Tests for i386(x86) are pending as we haven't dealt with that triple yet as compared to CG.
…r calls to memcpy (llvm#1677)
- Generalizes CIRFPTypeInterface files to CIRTypeInterfaces for future type interfaces additions. - Renames CIRFPTypeInterface to FPTypeInterface. - Fixes FPTypeInterface tablegen prefix.
This resolves issues pointed out in https://github.com/llvm/llvm-project/pull/143960/files#r2164047625 of needing to update sized list of types on each new type.
Implement CompoundLiteralExpr for ComplexType
Backporting the VecShuffleOp folder
…llvm#1716) We lower `cir::ForOp` into `cir::WhileOp` (rather than `scf::WhileOp`) when it contains break and continue. This is to reuse the rewriting functions already implemented for while loops. Co-authored-by: Yue Huang <yue.huang@terapines.com>
Support codgen for GenericSelectionExpr
Implement PackIndexingExpr for ScalarExpr
…lvm#1720) Fix the verifier error messages from `unexpected error: 'cir.complex.imag' op cir.complex.imag result type does not match operand type` to `unexpected error: 'cir.complex.imag' op : result type does not match operand type`
Backporting the VecShuffleDynamicOp folder
PR for llvm#1791 --------- Co-authored-by: yotto3s <yupon.tysm@gmail.com>
Backport global initializer for ComplexType from the upstream
Use ZeroInitAttr to initialize a null value for a ComplexType with 0 number of inits, not building ConstComplexType similar to the upstream
closes llvm#1794 This PR adds support for the `__sync_lock_set_and_set` builtin. Signed-off-by: vishruth-thimmaiah <vishruththimmaiah@gmail.com>
Backport the VisitCXXDefaultArgExpr support for ComplexType from the upstream
The builder create methods are deprecated: https://mlir.llvm.org/deprecation/. See https://discourse.llvm.org/t/psa-opty-create-now-with-100-more-tab-complete/87339.
A simple clean up, just some small changes for the use explicitly types instead of `auto`. In the case of `BI__builtin_ia32_pslldqi*_byteshift`. Following the suggestion of this comment: llvm#1886 (comment)
**Related Issue**: llvm#1885
…lvm#1965) The goal of this PR is to prepare the code for backporting the new implementations of Arith operations for ComplexType and other expressions support - Reorder the functions in CIRGenExprComplex similar to upstream and classical codegen. - Remove unnecessary functions `emitAddrOfRealComponent` and `emitAddrOfImagComponent`. - The updated code style is to be similar to upstream.
Use the op create function in the CirGenExprComplex file after the restructure
This backports a problem I noticed while upstreaming constant initialization of automatic aggregate variables. Even though the aggregate is being initialized, we weren't setting the `init` attribute. There is one odd case where the constant being used to initialize a class is an undef. OGCG does the same thing. In this patch I'm not attempting to detect that case, and I'm not sure if we should.
Adds support for the `__sync_swap` builtin. Signed-off-by: vishruth-thimmaiah <vishruththimmaiah@gmail.com>
monthdev
force-pushed
the
fix-delete-array
branch
from
5ef1b0b to
ff0bf89
Compare
Backporting support for logical not for VectorType from the upstream
Backport support for GNUNullExpr from the upstream
monthdev
force-pushed
the
fix-delete-array
branch
from
a6f85b0 to
c558cf6
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
30 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Addressing #165225