Page MenuHomePhabricator

Expose non-trivial struct helpers for Swift.

Authored by allevato on Apr 2 2019, 3:57 PM.



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 to
enable it to import such C records.

Event Timeline

allevato created this revision.Apr 2 2019, 3:57 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 2 2019, 3:57 PM
rjmccall added inline comments.Apr 3 2019, 2:44 PM

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.

allevato added inline comments.Apr 3 2019, 2:59 PM

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.

allevato updated this revision to Diff 194379.Apr 9 2019, 12:27 PM
  • Apply review changes
allevato marked an inline comment as done.Apr 9 2019, 12:27 PM
rjmccall added inline comments.

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.


The parameter name is different from the one that is used in the function definition (CharUnits DstAlignment). Ditto for generateNonTrivialCStructDestructor.


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.

allevato updated this revision to Diff 194530.Apr 10 2019, 9:06 AM
  • Rename generate* to get* and cleanup param names.
allevato marked 2 inline comments as done.Apr 10 2019, 9:09 AM

Thanks for the review! This is ready to go on my end if there aren't any other comments.


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.

rjmccall accepted this revision.Apr 10 2019, 9:25 AM

LGTM, thanks.

This revision is now accepted and ready to land.Apr 10 2019, 9:25 AM

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!

rjmccall closed this revision.Apr 10 2019, 12:55 PM

Committed as r358132.