[IRGen] Re-introduce TypeLayout strings #62059
Conversation
Layout strings encode the structure of a type into a byte string that can be interpreted by a runtime function to achieve a destroy or copy. Rather than generating ir for a destroy/assignWithCopy/etc, we instead generate a layout string which encodes enough information for a called runtime function to perform the operation for us. Value witness functions tend to be quite large, so this allows us to replace them with a single call instead. This gives us the option of making a codesize/runtime cost trade off.
This marks a type definition that should use generic bytecode based value witnesses rather than generating the standard suite of value witness functions. This should reduce the codesize of the binary for a runtime interpretation of the bytecode cost.
Summary: This creates a library to store the runtime functions in to deploy to runtimes that do not implement bytecode layouts. Right now, that is everything. Once these are added to the runtime itself, it can be used to deploy to old runtimes.
If GenerateLayoutBytecode is enabled, Create a layout string and use it to call swift_generic_destroy
Add Resilient type and Archetype Support to Bytecode Layouts
Implements swift_generic_initialize and swift_generic_assign to allow copying types using bytecode based witnesses.
Added a test to ensure layouts are correct and getting generated
MultiEnums currently have some correctness issues with non fixed multienum types. Disabling them for now then going to attempt a correct implementation in a follow up patch
|
@swift-ci smoke test |
drexin
force-pushed
the
wip-struct-layouts
branch
from
7a467f2 to
60a2a39
Compare
|
@swift-ci smoke test |
drexin
force-pushed
the
wip-struct-layouts
branch
from
60a2a39 to
3a81f72
Compare
|
@swift-ci smoke test |
|
@swift-ci smoke test |
|
@swift-ci smoke test |
|
@swift-ci smoke test |
|
@swift-ci smoke test |
drexin
force-pushed
the
wip-struct-layouts
branch
from
ff34261 to
57a675e
Compare
|
@swift-ci smoke test |
|
@swift-ci smoke test macos |
|
@swift-ci smoke test macos |
1 similar comment
|
@swift-ci smoke test macos |
|
@swift-ci smoke test macos |
| if (!IGM.getOptions().ForceStructTypeLayouts) { | ||
| return IGM.typeLayoutCache.getOrCreateTypeInfoBasedEntry(*this, T); | ||
| } | ||
| return IGM.typeLayoutCache.getOrCreateScalarEntry( |
There was a problem hiding this comment.
I suspect we will want to communicate the number of witness tables here in the future. The protocol witness table pointers are part of the layout of an existential type.
Maybe by building an aligned entry group that starts with a scalar entry of an existential reference (modeling the storage only) and then trailing pod scalar entries for the witnesses. (Hmm does that correctly capture the extra inhabitants/spare spits -- would need investigation)
| case ScalarKind::POD: { | ||
| assert(typeInfo.isFixedSize()); | ||
| Size size = cast<FixedTypeInfo>(typeInfo).getFixedSize(); | ||
| switch (size.getValueInBits()) { |
There was a problem hiding this comment.
This does not handle i1 (bool).
| // | ||
| // enum class LayoutType: char { | ||
| // // Scalars | ||
| // I8 = 'c', |
There was a problem hiding this comment.
Missing (at least) i1.
There was a problem hiding this comment.
I don't think the scalar encoding as is is sufficient. LLVM builtin types are available -- eventually, we need to be able to match/encode the results of getSpareBitsForType.
…eLayouts is disabled
drexin
force-pushed
the
wip-struct-layouts
branch
from
57a675e to
93eadca
Compare
|
@swift-ci smoke test |
|
@swift-ci smoke test |
|
@swift-ci smoke test |
|
@swift-ci smoke test |
Layout strings encode the structure of a type into a byte string that can be
interpreted by a runtime function to achieve a destroy or copy. Rather than
generating ir for a destroy/assignWithCopy/etc, we instead generate a layout
string which encodes enough information for a called runtime function to
perform the operation for us. Value witness functions tend to be quite large,
so this allows us to replace them with a single call instead. This gives us the
option of making a codesize/runtime cost trade off.