This change exposes the helper functions that generate ctors/dtors
for non-trivial structs so that they can be called from the Swift
compiler (see https://github.com/apple/swift/pull/23405) to
enable it to import such C records.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
- Build Status
Buildable 30318 Build 30317: arc lint + arc unit
Event Timeline
clang/include/clang/CodeGen/CodeGenABITypes.h | ||
---|---|---|
92 | Hmm. I think it might be better to just have this return a function pointer; emitting a call in a different frontend's function can be pretty fraught if that frontend wants to handle e.g. unwinding. The interface should document the ABI of the returned function pointer. Callers might be able to take advantage of a function pointer in different ways, e.g. by using it directly in Swift's value-witness tables on targets where the calling conventions align. In the long run, I'd definitely like to make this interface capable of doing some limited code-generation tasks, e.g. to load or store bit-fields, but I suspect that we'll need to think about that a bit more carefully and that we might want to avoid anything that involves a call. |
clang/include/clang/CodeGen/CodeGenABITypes.h | ||
---|---|---|
92 | That makes sense—getting this working was a bit tricky and passing the BB and insert point didn't exactly seem like the cleanest approach. I'll work on the alternate approach you suggested and circle back around when I have it working with the corresponding Swift changes. |
clang/include/clang/CodeGen/CodeGenABITypes.h | ||
---|---|---|
140 | Would you mind calling these get... rather than generate...? It'd make it clearer that they will re-use an existing definition if possible. Otherwise this looks great, thanks! Akira, any comments? |
Just one minor comment, but otherwise the patch looks good to me.
clang/include/clang/CodeGen/CodeGenABITypes.h | ||
---|---|---|
92 | The parameter name is different from the one that is used in the function definition (CharUnits DstAlignment). Ditto for generateNonTrivialCStructDestructor. | |
clang/lib/CodeGen/CGNonTrivialStruct.cpp | ||
845 | I think getFunction shouldn't require passing addresses, but that's not this patch's fault. I'll see if I can remove the parameter. |
Thanks for the review! This is ready to go on my end if there aren't any other comments.
clang/lib/CodeGen/CGNonTrivialStruct.cpp | ||
---|---|---|
845 | Yeah, this hack bummed me out and I tried cleaning up the other related functions to have them not reuse the array in this way, but the way std::array and the template arg size_t N are currently being used throughout made those attempts ripple through in ways that would have required a deeper refactor. |
Oh, and in case I need to mention this (I don't contribute to llvm/clang frequently), I don't have commit access so I'll need someone else to merge it in. Thanks!
Hmm. I think it might be better to just have this return a function pointer; emitting a call in a different frontend's function can be pretty fraught if that frontend wants to handle e.g. unwinding. The interface should document the ABI of the returned function pointer. Callers might be able to take advantage of a function pointer in different ways, e.g. by using it directly in Swift's value-witness tables on targets where the calling conventions align.
In the long run, I'd definitely like to make this interface capable of doing some limited code-generation tasks, e.g. to load or store bit-fields, but I suspect that we'll need to think about that a bit more carefully and that we might want to avoid anything that involves a call.