IRGen: generate static arrays in read-only data sections. #59431
Conversation
|
@swift-ci test |
|
@swift-ci benchmark |
| // the metadata of the empty array buffer. The important thing is that its | ||
| // deinit is a no-op and does not actually destroy any elements. | ||
| __asm__(" .globl __swiftStaticArrayMetadata\n"); | ||
| __asm__(".set __swiftStaticArrayMetadata, _$ss19__EmptyArrayStorageCN\n"); |
There was a problem hiding this comment.
I'm thinking this should become the real metadata symbol, and _$ss19__EmptyArrayStorageCN should be an alias to it. If we're expanding its use cases, then EmptyArrayStorage is no longer an accurate name.
There was a problem hiding this comment.
We can do this later. It would required renaming the EmptyArrayStorage class. I don't want to introduce too much churn here.
|
Big fan here. Would this make sense for other containers at the moment? I haven't checked how |
eeckstein
force-pushed
the
read-only-static-arrays
branch
from
b74d377 to
89a4907
Compare
|
@swift-ci test |
|
@apple-fcloutier Putting |
|
Thanks, I figured that might be the case. We'll take note of the limitation for now. |
| #error("unsupported pointer width") | ||
| #endif | ||
|
|
||
| // Static arrays can only contain trivial elements. Therefore we can reuse |
There was a problem hiding this comment.
Do the elements necessarily need to be trivial? Or is the important thing that their lifetimes are all statically known and don't need runtime refcounting? (I guess that is "trivial" - but trivial value as opposed to trivial type)
For example, would this work with an Array<Array<Int>> (assuming the inner arrays are also array literals)?
There was a problem hiding this comment.
Yes, elements need to be trivial, i.e. must not contain any reference counted objects. One exception is String literals: String literals can be put into the data section, too (Note that String is not a trivial type).
Nested arrays are not supported. But we could support it in the future.
The layout of constant static arrays differs from non-constant static arrays. Therefore use a different mangling to get symbol mismatches if for some reason two modules don't agree on which version a static array is.
Expands to, e.g. `x86_64-apple-macosx99.99` This is useful to test features which are available in a "future" runtime.
* `__swiftImmortalRefCount`: The bit pattern of the ref-count field of immortal objects * `__swiftStaticArrayMetadata`: The metadata used for static arrays.
So far, static arrays had to be put into a writable section, because the isa pointer and the (immortal) ref count field were initialized dynamically at the first use of such an array. But with a new runtime library, which exports the symbols for the (immortal) ref count field and the isa pointer, it's possible to put the whole array into a read-only section. I.e. make it a constant global. rdar://94185998
eeckstein
force-pushed
the
read-only-static-arrays
branch
from
89a4907 to
aca0d83
Compare
|
@swift-ci test |
So far, static arrays had to be put into a writable section, because the isa pointer and the (immortal) ref count field were initialized dynamically at the first use of such an array.
But with a new runtime library, which exports the symbols for the (immortal) ref count field and the isa pointer, it's possible to put the whole array into a read-only section. I.e. make it a constant global.
Also, those array symbols get a new mangling to not mix it up with the old non-constant array symbols.
rdar://94185998