The alias defined here with the `.set` directive doesn't actually define a symbolic alias
that the linker respects in all cases. The resulting standard library dylib _does_ contain a
reference to the aliased symbol with the correct value, but the resulting variable is not actually
considered relocatable by the linker. Thus, its value may not always get fixed up properly.
Work around this by dropping the alias for now - directly use the type metadata for Swift.__EmptyArrayStorage
instead.
rdar://100288247
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
This reverts the revert commit df353ff3c0.
Also, I added a frontend option to disable this optimization: `-disable-readonly-static-objects`
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
In the new string implementation there is a subtract of a (small) constant from the literal pointer. We convert
((ptr - offset) | bits
to
(ptr + (bits - offset))
which can still be represented as a relocation.
print and parse as a stable hexadecimal form that isn't interpreted as UTF8.
One use case is in representing serialized protobuf strings (as in the
tensorflow branch: f7ed452eba/lib/SILOptimizer/Mandatory/TFPartition.cpp (L3875)).
The original work was done by @lattner and merged into the tensorflow
branch. This PR is to upstream those changes.
So there is no need to initialize global string variables dynamically (with dispatch_once) anymore.
This is much more efficient, both in terms of code size and performance
The main part of the change is to support the ptr_to_int builtin in statically initialized globals. This builtin is used to build a StaticString from a string_literal.
On the other hand I removed the support of the FPTrunc builtin, which is not needed anyway (because it can be constant propagated).
This commit contains:
-) adding the new instructions + infrastructure, like parsing, printing, etc.
-) support in IRGen to generate global object-variables (i.e. "heap" objects) which are statically initialized in the data section.
-) IRGen for global_value which lazily initializes the object header and returns a reference to the object.
For details see the documentation of the new instructions in SIL.rst.
We don't want the machine calling conventions for closure invocation functions to necessarily be tied to the convention for normal thin functions or methods. NFC yet; for now, 'closure' follows the same behavior as the 'method' convention, but as part of partial_apply simplification it will be a requirement that partial_apply takes a @convention(closure) function and a box and produces a @convention(thick) function from them.
Previously there was a mismatch between SIL's concept of a
struct (padding is implicit) and LLVM's (padding is explicit) in IRGen's
constant evaluator. The explicit padding fields need to be given a value
in the IR.
This patch also moves the (currently small) list of constant evaluation
functions into their own file.
Fixes SR-716.
