> On Jun 15, 2017, at 4:26 PM, Andrew Trick <atr...@apple.com> wrote: > > >> On Jun 14, 2017, at 12:03 PM, Jordan Rose via swift-dev <swift-dev@swift.org >> <mailto:swift-dev@swift.org>> wrote: >> >>> ad 3) IRGen support >>> >>> Generating statically initialized globals is already done today for structs >>> and tuples. >>> What’s needed is the handling of objects. >>> In addition to creating the global itself, we also need a runtime call to >>> initialize the object header. In other words: the object is statically >>> initialized, except the header. >>> >>> HeapObject *swift::swift_initImmortalObject(HeapMetadata const *metadata, >>> HeapObject *object) >>> >>> There are 2 reasons for that: first, the object header format is not part >>> of the ABI. And second, in case of a bound generic type (e.g. array >>> buffers) the metadata is not statically available. >>> >>> One way to call this runtime function is dynamically at the global_object >>> instruction whenever the metadata pointer is still null (via swift_once). >>> Another possibility would be to call it in a global constructor. >>> >>> If you have any feedback, please let me know >> >> Please do not use a global constructor. > > What’s the objection to a global constructor about? We’re worried about dyld > performance in this case? > >> :-) > > :-/ > >> Globals are already set up to handle one-time initialization; the fact that >> that initialization is now cheaper is still a good thing. > > > These array literals aren’t Swift globals to begin with so I’m not sure what > that means. Introducing a swift-once accessor everywhere they’re used means > we can’t do the global optimizations that we normally do for globals with > constant initializers. That might be the right choice but it would be good to > understand why we’re making it.
Erik answered this. I forgot we need to initialize metadata. I agree we don’t want to do that in a global constructor. The fast path won’t go through swift-once, so the accessor will be just a bit of extra code size. -Andy
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
