Skip to content

Conversation

ahmedshakill
Copy link
Contributor

Implements #1812

Copy link

github-actions bot commented Aug 24, 2025

✅ With the latest revision this PR passed the C/C++ code formatter.

Copy link
Collaborator

@tommymcm tommymcm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm, some nits

@ahmedshakill ahmedshakill requested a review from tommymcm August 25, 2025 06:16
Copy link
Collaborator

@tommymcm tommymcm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CIRGen lgtm
Some more changes for the test to format it correctly and make it more readable.

Copy link
Collaborator

@tommymcm tommymcm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

Copy link
Member

@bcardosolopes bcardosolopes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM after minor comment


QualType thisTy =
IsArrow ? Base->getType()->getPointeeType() : Base->getType();
emitCXXDestructorCall(globalDecl, callee, This.getPointer(), thisTy,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see some code repetition from the else part, that can be improved overall

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Classic codegen, calls CGM.getCXXABI().EmitVirtualDestructorCall() here. Is there a reason we can't do that?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CGM.getCXXABI().EmitVirtualDestructorCall()

Thanks for the suggestion. We can use this call instead. Got the same result.

@ahmedshakill
Copy link
Contributor Author

Qualified explicit destructor call has different behavior compared to Non-Qualified destructor call.

qualifying destructor

Qualified explicit destructor call is already handled in the CIR Codegen. Only Unqualified call needs to be handled.

CIR qualifying destructor

@tommymcm
Copy link
Collaborator

Qualified explicit destructor call has different behavior compared to Non-Qualified destructor call.

qualifying destructor Qualified explicit destructor call is already handled in the CIR Codegen. Only Unqualified call needs to be handled. CIR qualifying destructor

Sounds good, is there any issue here or did you just want to clarify?

@ahmedshakill
Copy link
Contributor Author

@tommymcm Just wanted to clarify.

Copy link
Collaborator

@tommymcm tommymcm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Needs some more info in the tests, once that's done I think it will all lgtm

@@ -19,5 +24,27 @@ A A::B(A) {
// CIR-NEXT: cir.trap
// CIR-NEXT: }


// LLVM-LABEL: define dso_local %class.A @_ZN1A1BES_(
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test has some loose ends.
Could you add the this argument binding and store, that way we can tie everything together. Something like

// LLVM-LABEL: ...
// LLVM-SAME:     %[[THIS_ARG:.*]]
// ...
// LLVM:          %[[THIS_VAR:.*]] = alloca ptr
// ...
// LLVM:          store ptr %[[THIS]], ptr %[[THIS_VAR]]
// ...
// LLVM:          %[[THIS:.*]] = load ptr, ptr %[[THIS_VAR]]

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same for OGCG.

// LLVM: %[[VAL_0:.*]] = alloca ptr, i64 1, align 8
// LLVM: %[[VAL_6:.*]] = load ptr, ptr %[[VAL_0]], align 8
// LLVM-NEXT: %[[VAL_7:.*]] = load ptr, ptr %[[VAL_6]], align 8
// LLVM-NEXT: %[[VAL_8:.*]] = getelementptr inbounds ptr, ptr %[[VAL_7]], i32 0
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Name these variables, for example:

Suggested change
// LLVM-NEXT: %[[VAL_8:.*]] = getelementptr inbounds ptr, ptr %[[VAL_7]], i32 0
// LLVM-NEXT: %[[VIRT_DTOR_ADDR:.*]] = getelementptr inbounds ptr, ptr %[[THIS]], i32 0

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, I'll look into them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants