-
Notifications
You must be signed in to change notification settings - Fork 100
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[CIR][CIRGen] Introduce cir.delete.array op #1172
base: main
Are you sure you want to change the base?
Conversation
Neat, the direction makes sense to me. You may also be interested in #1055 as a somewhat similar area where we want to design a high-level representation, btw – if there's something we could do there that would help your analysis, we'd love to hear about it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, way to go.
Approach LGTM, minor nits around!
|
||
def DeleteArrayOp : CIR_Op<"delete.array">, | ||
Arguments<(ins CIR_PointerType:$address)> { | ||
let summary = "Delete address representing an array"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you add an example as part of the description
?
clang/lib/CIR/Dialect/Transforms/LoweringPrepareItaniumCXXABI.h
Outdated
Show resolved
Hide resolved
e679d2c
to
38d4f20
Compare
38d4f20
to
5f47b83
Compare
// We might be deleting a pointer to array. If so, GEP down to the | ||
// first non-array element. | ||
// (this assumes that A(*)[3][7] is converted to [3 x [7 x %A]]*) | ||
// In CIRGen: we handle this differently because .... .. .. . . |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, the trailing dots were not literal haha, just a placeholder for you to mention what you need to mention :)
I am working on a clangir based solution to improve C++'s safety (https://discourse.llvm.org/t/rfc-a-clangir-based-safe-c/83245). This is similar with the previous analysis only approach I proposed, where we may not care about the lowered code. And this is what I described as layering problems in https://discourse.llvm.org/t/rfc-a-clangir-based-safe-c/83245
This is similar with the other issue proposed #1128. We'd better to emit the higher level operations and lowering/optimizing it later.
This is also inspired our handling method for VAArg, where we use ABI information to lower things during the passes. It gives me more confidence that I am doing things right.